idnits 2.17.1 draft-ietf-calsch-imip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 90 longer pages, the longest (page 2) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 22 instances of too long lines in the document, the longest one being 67 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 226: '... SHOULD provide support for:...' RFC 2119 keyword, line 369: '...gated as request MUST inherit the RSVP...' RFC 2119 keyword, line 382: '...r value of IMMEDIATE MUST not be used....' RFC 2119 keyword, line 388: '...SCRIPTION property in a recipient MUST...' RFC 2119 keyword, line 389: '... Implementations MAY truncate longer l...' (93 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 605 has weird spacing: '...y value stan...' == Line 709 has weird spacing: '...ld this meeti...' == Line 1073 has weird spacing: '...atus to mess...' == Line 1578 has weird spacing: '...y value stan...' == Line 2312 has weird spacing: '...y value stan...' == (4 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The EXPECT property parameter value of IMMEDIATE MUST not be used. This semantic is provided by the RSVP property parameter value of YES. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Duplicate busy time periods SHOULD not be specified in an iCalendar Object. However, two different busy time periods may overlap. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1997) is 9656 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 822' is mentioned on line 269, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Unused Reference: 'ID-DT' is defined on line 4539, but no explicit reference was found in the text == Unused Reference: 'ID-UTF8' is defined on line 4549, but no explicit reference was found in the text == Unused Reference: 'ISO8601' is defined on line 4553, but no explicit reference was found in the text == Unused Reference: 'VCAL' is defined on line 4557, but no explicit reference was found in the text == Unused Reference: 'VCARD' is defined on line 4561, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 4569, but no explicit reference was found in the text == Unused Reference: 'US-ASCII' is defined on line 4577, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-CSP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-DT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ICAL' -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-UTF8' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' -- Possible downref: Non-RFC (?) normative reference: ref. 'VCAL' -- Possible downref: Non-RFC (?) normative reference: ref. 'VCARD' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' Summary: 12 errors (**), 0 flaws (~~), 20 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Frank Dawson, Lotus 3 Internet Draft 4 May 1, 1997 5 Expires November 1997 7 iCalendar Message-based Interoperability Protocol (iMIP) 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced, or made obsolete by 18 other documents at any time. It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Distribution of this document is unlimited. 30 Abstract 32 This document defines an iCalendar Message-based Interoperability 33 Protocol (iMIP), intended to be used to convey calendaring and 34 scheduling semantics between different applications. This document is 35 also being offered as a specification for demonstrating industry- 36 wide, calendaring and scheduling interoperability. 38 The message-based protocol defined by this document is useful not 39 only in traditional electronic messaging (e-mail) transports, but 40 also is applicable for conveying calendaring and scheduling 41 information across any reliable transport; including memory-based 42 clipboards, drag/drop protocols, wireless pagers, and the Infra-red 43 Data Association (IrDA) object transfer protocol. This format is 44 useful for both client-to-server communication, server-to-server 45 communication, and client-to-client, peer communication (e.g., PDA 46 synchronization with a PIM). 48 This design document is heavily based on the prior work of the Versit 49 Consortium's Personal Data Interchange (PDI) project team; including 50 the vCard v2.1 and the vCalendar v1.0 specifications. More 51 information about the PDI project and these documents can be found on 52 the Internet Mail Consortium (IMC) website at http://www.imc.org/pdi. 54 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 55 May 1, 1997 57 In addition, this design document makes use of the work within the 58 Internet Engineering Task Force (IETF) Calendaring and Scheduling 59 (CALSCH) working group. More information about the IETF CALSCH 60 working group activities can be found on the IMC website at 61 http://www.imc.org, the IETF website at 62 http://www.ietf.org/html.charters/calsch-charter.html. Refer to the 63 references within this document for further information on how to 64 access these various documents. 66 Distribution of this document is unlimited. Comments and suggestions 67 for improvement should be sent as MIME email to the author. 69 Table of Contents 71 1. Intended Use........................................................3 72 1.1 Desktop Interoperablity ..........................................4 73 2. Message Based Architecture..........................................5 74 3. iCalendar Support...................................................6 75 3.1 Differences From iCalendar .......................................6 76 3.1.1 Character Set .................................................7 77 3.1.2 ATTENDEE Property .............................................7 78 3.1.3 DESCRIPTION Property ..........................................7 79 3.1.4 SUMMARY Property ..............................................8 80 3.1.5 PRODID Property ...............................................8 81 3.1.6 VERSION Property ..............................................8 82 3.1.7 PROFILE Property ..............................................8 83 3.1.8 PROFILE-VERSION Property ......................................9 84 3.1.9 UID Property ..................................................9 85 3.1.10 RELATED-TO Property ..........................................9 86 3.1.11 URL Property .................................................9 87 3.1.12 REQUEST-STATUS Property .....................................10 88 3.1.12.1 COMMENT Property ........................................13 89 3.2 Free and Busy Time ..............................................13 90 3.2.1 Freebusy Calendar Component ..................................14 91 3.2.2 FREEBUSY Property ............................................14 92 4. Supported Capability...............................................14 93 4.1 Request and reply to an event ...................................15 94 4.2 Cancel an event .................................................16 95 4.3 Request and reply to a to-do ....................................17 96 4.4 Negotiate an alternate event definition .........................18 97 4.5 Delegate an event to another individual .........................20 98 4.6 Request and reply for busy time .................................21 99 5. Message Profile Specifications.....................................22 100 6. Message Types......................................................24 101 6.1 EVENT-REQUEST ...................................................24 102 6.2 EVENT-REPLY .....................................................27 103 6.3 EVENT-CANCEL ....................................................32 104 6.4 EVENT-REPLACE ...................................................35 105 6.5 EVENT-COUNTER ...................................................38 106 6.6 EVENT-DECLINECOUNTER ............................................41 107 6.7 EVENT-DELEGATE ..................................................46 108 6.8 TODO-REQUEST ....................................................50 109 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 110 May 1, 1997 112 6.9 TODO-REPLY ......................................................54 113 6.10 TODO-CANCEL ....................................................58 114 6.11 JOURNAL-REQUEST ................................................61 115 6.12 JOURNAL-REPLY ..................................................63 116 6.13 BUSY-REQUEST ...................................................66 117 6.14 BUSY-REPLY .....................................................69 118 7. MIME Message Format Binding........................................74 119 7.1 MIME Media Type .................................................74 120 7.2 Security ........................................................74 121 7.3 RFC 822 Addresses ...............................................74 122 7.4 Content Type ....................................................75 123 7.5 Content-Transfer-Encoding .......................................75 124 7.6 Content-Description .............................................76 125 7.7 To ..............................................................76 126 7.8 From ............................................................76 127 7.9 Cc and Bc .......................................................76 128 7.10 Reply-To .......................................................76 129 7.11 Subject ........................................................76 130 8. Alternate Plain-text Messages......................................76 131 8.1 EVENT-REQUEST, RSVP=YES .........................................77 132 8.2 EVENT-REQUEST, RSVP=NO ..........................................77 133 8.3 EVENT-REQUEST, EXPECT=REQUIRED ..................................78 134 8.4 EVENT-CANCEL ....................................................79 135 8.5 EVENT-REPLACE, RSVP=YES .........................................79 136 8.6 EVENT-DECLINECOUNTER ............................................80 137 8.7 EVENT-DELEGATE, RSVP=YES ........................................81 138 8.8 TODO-REQUEST, RSVP=YES ..........................................82 139 8.9 TODO-REQUEST, RSVP=NO ...........................................82 140 8.10 TODO-CANCEL ....................................................83 141 8.11 JOURNAL-REQUEST, RSVP=YES ......................................84 142 8.12 JOURNAL-REQUEST, RSVP=NO .......................................84 143 9. IrDA Binding.......................................................85 144 10. TCP LAN Protocol Binding..........................................85 145 11. SPX LAN Protocol Binding..........................................85 146 12. Desktop Interaction Requirements..................................85 147 12.1 Clipboard ......................................................85 148 12.2 Drag/Drop ......................................................85 149 12.3 File System ....................................................86 150 12.4 IrDa Communications ............................................86 151 13. Conformance.......................................................86 152 14. References........................................................86 153 15. Acknowledgements..................................................87 154 16. Author's Address..................................................87 155 17. Issues............................................................88 156 18. Resolutions.......................................................88 158 1. Intended Use 160 This document defines a set of message types that provide a full set 161 of inter-personal scheduling semantics. These capabilities include 162 the following: 164 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 165 May 1, 1997 167 . Request that an event or to-do be scheduled on one or more 168 recipients calendars; 170 . Reply to an existing event or to-do request to confirm, decline, 171 tentative, or delegate the request; 173 . Allow a recipient of an event request to forward it to one or more 174 delegated recipients; 176 . Allow the originator of an event to cancels the event; 178 . Allow the originator of an event to replace the original event 179 definition, as when an event is rescheduled or the attendee 180 information is updated; 182 . Allow a recipient of an event request to send the originator a 183 counter-proposal; 185 . Allow the originator of an event request to decline a counter 186 proposal from an attendee; 188 . Request busy time data from one or more recipients; 190 . Reply to a busy time request with busy time data; 192 . Support Internet protocol access to C&S capability; 194 . Support LAN protocol access to C&S capability; 196 . Allow specification of a recurring event description with a 197 recurrence grammar, a sequence of events, or a combination of the 198 two. Recurrence grammar will allow Yearly-by-day-position, 199 Monthly-by-days-of-week, Monthly-by-day-position, Weekly-by-days- 200 of-week, Weekly-by-position, Daily-by-time; 202 . Support scheduling a meeting between individuals in different time 203 zones; 205 . Support for time zones; 207 . Support for DST rules; and 209 . Attachment of files to an event or to-do request. 211 In addition, the following real-time functions are supported: 213 . Request a busy time URL from an LDAP server; and 215 . Retrieve busy time from a busy time URL. 217 1.1 Desktop Interoperablity 219 This document was not explicitly intended to address application 220 interoperability at the desktop. However, in order to maximize the 221 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 222 May 1, 1997 224 largest possible interoperability between applications, the following 225 recommendations are provided. Applications supporting this document 226 SHOULD provide support for: 228 . Drag/source of calendar data, rendered as an iCalendar Object, 229 using both clipboard and file based drag/drop protocols; 231 . Drop/target of an iCalendar Object using both clipboard and file 232 based drag/drop protocol; 234 . Clipboard/Copy of a calendar data rendered as an iCalendar Object; 236 . Clipboard/Paste of a iCalendar Object from the clipboard; 238 . File/Open of an iCalendar Object from the file system; 240 . File/SaveAs of calendar data as an iCalendar Object to the file 241 system;. 243 . Ability to invoke the product with an iCalendar Object as an 244 argument list item. 246 . Send calendar data, rendered as an iCalendar Object, over the 247 Win95/NT infra-red port; and 249 . Receive an iCalendar Object from the infra-read port. 251 2. Message Based Architecture 253 The calendaring and scheduling capability defined by this document is 254 based on the exchange of messages between an organizer of an event or 255 to-do and the attendees of the group event or to-do. For the most 256 part, the message protocol emulates a "request" and "reply" form of 257 communications. 259 The message format is designed to be used with a MIME electronic 260 messaging transport, but is equally applicable to other non-Internet 261 message transports. 263 The messages that define this inter-personal scheduling protocol 264 consist of an iCalendar Object defined by [ICAL]. 266 Depending on the transport used to convey the protocol, additional 267 message header properties may be used to further encapsulate the 268 iCalendar Object. For example, within a MIME [RFC2045] transport the 269 [ICAL] object will be encapsulated within a [RFC 822] message entity. 270 Other transports may not further encapsulate the iCalendar Object. 272 This message-based protocol is based "request" messages that are send 273 from an originator to one or more recipients. A recipient of a 274 "request" message may "reply" to the request, in order to update 275 their status as an attendee and may also return transaction/request 276 status information. In the case of event requests, the recipient may 277 alternatively respond to the request with a counter proposal. The 278 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 279 May 1, 1997 281 protocol also supports the ability for the originator of an event or 282 to-do request to cancel the original request. The originator of a 283 request may also replace the definition for the original request. 284 When the updated request changes the date, time or location of the 285 request, this effectively re-schedules the original request. 287 The originator of a request is by default the OWNER of the request. 288 Alternately, the originator may be the ORGANIZER of the request; 289 acting on behalf of the OWNER. The recipients of the request are by 290 default the ATTENDEES of the request. A recipient may delegate the 291 request to one of more individuals; in which case they would be a 292 DELEGATE of the request. The OWNER, ORGANIZER, ATTENDEE and DELEGATE 293 are role definitions that an attendee may be assigned by the OWNER of 294 the request. 296 The message-based protocol defined by this specification involves an 297 ORGANIZER/OWNER centric flow. Both the requests, cancellation, 298 replacement, acceptance of counter proposals can be originated only 299 from the ORGANIZER or OWNER of the request. 301 3. iCalendar Support 303 The messages used by this protocol are formatted according to the 304 IETF iCalendar specification [ICAL]. This document was selected as 305 the basis for the message types because it is the focus on an ongoing 306 effort to define an Internet calendaring and scheduling standard. 308 This document enhances the base [ICAL] specification with a minimum 309 of additional features. These include the following changes: 311 . iCalendar default character is UTF-8; 313 . Additional property parameter values for several properties; 315 . Extension to the URL property to allow reference to a busy time 316 data store; 318 . Constraints on some property values; 320 . Definition of a number of non-standard properties. The non- 321 standard properties where defined instead of new properties in 322 order to allow use of the currently available parser/generator 323 code base. 325 3.1 Differences From iCalendar 327 The basic capabilities defined by the [ICAL] document have utilized 328 to define a primarily "request" and "reply" based scheduling 329 protocol. In defining the protocol, some differences from the [ICAL] 330 specification have been introduced. The following sections describe 331 individual differences between the [ICAL] specification and this 332 design document. In addition, any constraints on the iCalendar 333 specification are defined. 335 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 336 May 1, 1997 338 3.1.1 Character Set 340 The default character set for iCalendar Objects conforming to this 341 specification is UTF-8. UTF-8 is the designation for a 8-bit form of 342 UNICODE that preserves the encoding of US-ASCII data, but also 343 provides for the inclusion of non-ASCII characters from the extended 344 Latin alphabet or any other character block supported by [UNICODE]. 345 This limitation will not impact existing applications that emit 346 iCalendar objects, but will facilitate applications that conform to 347 this design document to address current internationalization/national 348 language requirements. 350 3.1.2 ATTENDEE Property 352 The property parameters for this property have been extended to 353 include newly defined property parameters DELEGATED-TO, to indicate 354 the RFC 822 address of the individual that this attendee delegated 355 the request to, and DELEGATED-FROM to indicate the RFC 822 address of 356 the individual that this attendee received a delegated request from. 358 NOTE: These property parameters should be included in the current 359 [ICAL] document. 361 The DELEGATED-TO property parameter value is an (RFC 822) address 362 that represents the individual (e.g., "delegatee") that this request 363 has been deletated to. 365 The DELEGATED-FROM property parameter value is an (RFC 822) address 366 that represents the individual (e.g., "delegator") from whom this 367 request was delegated. 369 A recipient delegated as request MUST inherit the RSVP and EXPECT 370 values from the attendee that delegated the request to them. 372 The following is an example of this property with "delegatee" and 373 "delegator" information for an event: 375 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:John Smith 376 ATTENDEE;ROLE=DELEGATE;STATUS=TENTATIVE;DELEGATED-FROM= 377 iamboss@host2.com:Henry Cabot 378 ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED-TO= 379 hcabot@host2.com=iamboss(The Big Cheese)@host2.com 380 ATTENDEE;ROLE=DELEGATE;STATUS=ACCEPTED:Jane Doe 382 The EXPECT property parameter value of IMMEDIATE MUST not be used. 383 This semantic is provided by the RSVP property parameter value of 384 YES. 386 3.1.3 DESCRIPTION Property 388 The minimum support for the DESCRIPTION property in a recipient MUST 389 be for a 4095 byte value. Implementations MAY truncate longer length 390 values. 392 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 393 May 1, 1997 395 3.1.4 SUMMARY Property 397 The minimum support for the SUMMARY property in a recipient MUST be 398 for a 255 byte value. Implementations MAY truncate longer length 399 values. 401 3.1.5 PRODID Property 403 This property identifies the product that generated the iCalendar 404 object. This property MUST be included in an iCalendar object that 405 conforms to this design document. The value for Lotus products should 406 be based on an ISO 9070 formal public identifier text. The value for 407 Lotus products should be of the form: 409 prodid-value = ownerid ownerprefix textid 411 ownerd = "-//" 412 ;This specifies an unregistered owner identifier 414 ownerprefix = compname "/" prodname 416 textid = "//NONSGML" space version "//EN" 417 ;This specifies the NONSGML data entity, type of public text 418 ;class. The "EN" text tail specifies the natural language in 419 ;which the public text was written. 421 compname = 1*WORD 422 ;This is a unique text corresponding to the company name 424 prodname = 1*WORD 425 ;This is a unique text corresponding to the product family name 426 ;e.g., "Organizer" or "ccMail" 428 version = 429 ;e.g., "97 GS 19970314", "R5.0 19971216", "R8 19970214" 430 ;These examples need to be replaced with formally selected text 432 For example, the Lotus Organizer97 GS support for the iCalendar 433 object might be specified by the following: 435 -//Lotus/Organizer//NONSGML Organizer97 GS//EN 437 3.1.6 VERSION Property 439 The VERSION property identifies the particular version of the 440 iCalendar specification that the iCalendar object conforms to. The 441 [ICAL] specification uses the "2.0" text for its unique identifier. 442 This same value MUST be specified in iCalendar Objects conforming to 443 this document. 445 3.1.7 PROFILE Property 447 This property MUST be specified on any iCalendar Objects that conform 448 to this document. The property defines the usage profile or method 449 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 450 May 1, 1997 452 being conveyed by the iCalendar object. The value of this property 453 MUST be one of the values defined by this document. 455 When included in a MIME message entity, the value of this property 456 MUST be the same as the Content-Type profile parameter value. 458 3.1.8 PROFILE-VERSION Property 460 This property specifies the version of the profile that the messages 461 in the iCalendar object correspond with. For iCalendar messages that 462 conform to this design document, the value MUST be "0.9". 464 3.1.9 UID Property 466 Each event and to-do calendar entity MUST be identified with a 467 persistent, globally unique identifier. This identifier is created by 468 the calendar system that generates an iCalendar Object. The 469 identifier is represented as a text value. It is found in the UID 470 property within the iCalendar calendar component descriptions for the 471 event or to-do. Any message type that refers to the original EVENT- 472 REQUEST or TODO-REQUEST MUST use this same identifier as the value of 473 their UID property. For example, if individual "B" sends an EVENT- 474 COUNTER message to individual "A" (i.e., the OWNER and/or ORIGINATOR 475 of the EVENT-REQUEST), the EVENT-COUNTER message must include the UID 476 value from the original event request message. This is the method for 477 correlating scheduling messages with the referenced event or to-do. 479 The UID value for an instance of a recurrence rule is formatted such 480 that it consists of the UID of the initial event or to-do, followed 481 by the "/" SLASH character, followed by the date and time that the 482 recurrence instance starts. This agreement will allow recurrence 483 instances to uniquely identified. 485 3.1.10 RELATED-TO Property 487 The UID value is also used by the RELATED-TO property in order to 488 represent relationships among events and to-dos. For example, the 489 parent relationship of an event to a series of action items (i.e., 490 to-dos) may be show by the RELATED-TO property within the to-do 491 descriptions. The value of the RELATED-TO property would be the UID 492 of the parent event. Linkages between a sequence of events can also 493 be show by including RELATED-TO properties in each item in the event- 494 sequence, referencing back to the parent event. Backward traversal of 495 the sequence is completed when a referenced event or to-do is found 496 without a RELATED-TO property. 498 3.1.11 URL Property 500 The property definition of the URL property has been extended to 501 include the property parameter TYPE. The value BUSY may be specified 502 to indicate that the URL specifies the location of busy time data 503 associated with the originator of the message. For example, an 504 originator for an EVENT-REQUEST message may specify this property 505 parameter/value pair to specify the URL where the ATTENDEE might 506 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 507 May 1, 1997 509 search for busy time in order to construct a counter proposal. By 510 using the busy time data specified by this URL, a recipient might 511 determine an alternate free time for a counter proposal or a 512 rescheduling of an event. Multiple occurrences of the URL property 513 may indicate different resource locations. Busy time pointed to by a 514 busy time URL must be an iCalendar Object. 516 Editor's Note: Should there be additional constraints on the 518 format of a busy file URL? 520 3.1.12 REQUEST-STATUS Property 522 This newly defined property is identified by the property name 523 REQUEST-STATUS. This property is used to return status information 524 related to the processing of an associated iCalendar Object. The 525 property MUST only be used in an EVENT-REPLY, EVENT-DECLINECOUNTER, 526 TODO-REPLY, JOURNAL-REPLY or BUSY-REPLY message. The data type for 527 this property is TEXT. The value consists of a short return status, a 528 longer return status description, and optionally the offending data. 529 The components of the value are separated by the SEMICOLON character 530 (ASCII decimal 59). 532 NOTE: These property parameters should be included in the base [ICAL] 533 document. 535 The property is defined by the following notation: 537 rstatus = "REQUEST-STATUS" ":" statcode ";" 538 statdesc [";" extdata] 540 statcode = 3*DIGIT 541 ;Numeric return status code 543 statdesc = *WORD 544 ;Textual status description 546 extdata = *WORD 547 ;Textual exception data. For example, the offending property 548 ;name and value or complete property line. 550 The following are some examples of this property: 552 REQUEST-STATUS:0;Success 554 REQUEST-STATUS:101;Invalid property value;DTSTART\:96-Apr-01 555 ;Note escapement of the colon character in property value. 557 REQUEST-STATUS:201;Invalid Property Value;RRULE 559 REQUEST-STATUS:301;Event conflict. Date/time is busy. 561 REQUEST-STATUS:403;Invalid calendar user;ATTENDEE: 562 jsmith@host.com 563 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 564 May 1, 1997 566 The following are valid values for the short return status and the 567 longer return status description: 569 Short Return Longer Return Status Description 570 Status Value 572 0 Success 574 1XX Syntax value errors 576 2XX Semantic and value errors 578 3XX Scheduling errors 580 4XX Security related errors 582 The following is a list of possible exception values: 584 Short Return Longer Return Status Offending Data 585 Status Description 587 0 Success. None. 589 10 Success, but fallback 590 taken on one or more may be specified. Property name and value 591 property values. 593 11 Success, invalid Property name may be 594 property ignored. specified. 596 12 Success, invalid Property parameter name 597 property parameter and value may be 598 ignored. specified. 600 13 Success, unknown non- Non-standard property 601 standard property name may be specified. 602 ignored. 604 14 Success, unknown non- Property and non- 605 standard property value standard value may be 606 ignored. specified. 608 15 Success, invalid Calendar component 609 calendar component sentinel (e.g., 610 ignored. "BEGIN:ALARM") may be 611 specified. 613 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 614 May 1, 1997 616 16 Success, request Original and forwarded 617 forwarded to calendar RFC822 addresses may be 618 user. specified. 620 17 Success, repeating event RRULE or RDATE property 621 ignored. Scheduled as a name and value may be 622 single event. specified. 624 18 Success, truncated end DTEND property value may 625 date/time to date be specified. 626 boundary. 628 19 Success, repeating to-do RRULE or RDATE property 629 ignored. Scheduled as a name and value may be 630 single to-do. specified. 632 100 Invalid property name. Property name may be 633 specified. 635 101 Invalid property value. Property name and value 636 may be specified. 638 102 Invalid property Property parameter name 639 parameter. and value may be 640 specified. 642 103 Invalid property Property parameter name 643 parameter value. and value may be 644 specified. 646 104 Invalid calendar Calendar component 647 component sequence. sentinel may be 648 specified (e.g., 649 BEGIN:TIMEZONE). 651 201 Invalid date or time. Date/time value(s) may 652 be specified. 654 202 Invalid rule. Rule value may be 655 specified. 657 203 Request not supported. Profile property value 658 may be specified. 660 204 Invalid calendar user. Attendee property value 661 may be specified. 663 301 Event conflict. DTSTART and DTEND 664 Date/time is busy. property name and values 665 may be specified. 667 302 Request not supported. PROFILE property value 668 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 669 May 1, 1997 671 may be specified. 673 401 Service unavailable. ATTENDEE property value 674 may be specified. 676 402 Invalid calendar ATTENDEE property value 677 service. may be specified. 679 403 Invalid calendar user. ATTENDEE property value 680 may be specified. 682 404 No scheduling support ATTENDEE property value 683 for user. may be specified. 685 405 No authority. PROFILE and ATTENDEE 686 property values may be 687 specified. 689 3.1.12.1 COMMENT Property 691 This newly defined property is identified by the property name 692 COMMENT. The property is used to pass a comment text within the 693 calendar component. The property may use the ENCODING property 694 parameter to reset the default encoding to QUOTED-PRINTABLE in order 695 to include formatting characters within the comment text. For 696 example, the property can be used within an EVENT-REPLY to indicate 697 to the OWNER of an event request why an ATTENDEE is declining an 698 invitation. 700 NOTE: These property parameters should be included in the base [ICAL] 701 document. 703 The minimum support MUST be for a 4095 byte value. Implementations 704 MAY truncate longer length values. 706 The following is an example of this property. 708 COMMENT:The meeting really needs to include both ourselves 709 and the customer. We can't hold this meeting without them. 710 As a matter of fact, the venue for the meeting ought to be at 711 their site. - - Frank 713 3.2 Free and Busy Time 715 The [ICAL] specification provides support for representing free or 716 busy time data. This document only supports the request and replies 717 for busy-time information. 719 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 720 May 1, 1997 722 3.2.1 Freebusy Calendar Component 724 This design document only addresses the transfer of busy time 725 information. Applications desiring free time information must infer 726 this from available busy time information. The Freebusy Calendar 727 Component MUST only be used in order to provide busy time 728 information. The Freebusy Calendar Component MAY only appear in the 729 BUSY-REQUEST and BUSY-REPLY message types or in a network resource 730 containing busy time data. 732 The busy time periods within the iCalendar Object MAY be grouped into 733 more than one Freebusy Calendar Component. This capability allows 734 busy time periods to be grouped according to some common periodicity, 735 such as a calendar week, month, or year. In this case, each FREEBUSY 736 component needs to include the ATTENDEE, DTSTART and DTEND properties 737 to define the free busy information in order that in might be 738 unambiguous when stored separately. 740 3.2.2 FREEBUSY Property 742 An iCalendar Object conforming to document MUST restrict the use of 743 the BUSYTIME property for representing busy time information. 745 The FREEBUSY property value MAY include a list of values, separated 746 by the COMMA character (ASCII decimal 44). Alternately, multiple busy 747 time periods MAY be specified with multiple instances of the BUSYTIME 748 property. Both forms MUST be supported by implementations conforming 749 to this document. 751 Duplicate busy time periods SHOULD not be specified in an iCalendar 752 Object. However, two different busy time periods may overlap. 754 FREEBUSY properties SHOULD be sorted such that their values are in 755 ascending order, based on the start time, and then the end time, with 756 the earliest periods first. For example, today's busy time 757 information SHOULD appear before yesterday's busy time information. 758 And the busy time for this half hour SHOULD appear before the busy 759 time for earlier today. 761 Since events MAY span a day boundary, free busy time period MAY also 762 span a day boundary. 764 4. Supported Capability 766 The message types defined by this usage profile provides for the 767 scheduling functions that allow: 769 . An originator to request that an event be scheduled between 770 the originator and one or more recipients (EVENT-REQUEST); 772 . A recipient of an event request to reply to the originator of 773 the request (EVENT-REPLY); 774 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 775 May 1, 1997 777 . An originator of an existing event request to send a 778 cancellation notice to the attendees (EVENT-CANCEL); 780 . An originator of an existing event request to reschedule the 781 event (EVENT-REPLACE); 783 . An originator of an existing event request to send the 784 attendees an updated event description and attendee statuses 785 (also the EVENT-REPLACE); 787 . A recipient of an event request to delegate the request to 788 another recipient (EVENT-DELEGATE);A recipient of an event 789 request to send a counter proposal to the originator of the 790 request (EVENT-COUNTER); 792 . An originator of an existing event request to decline a 793 counter proposal from a recipient (EVENT-DECLINECOUNTER); 795 . An originator to request an action item or to-do to be 796 assigned to one or more recipients (TODO-REQUEST); 798 . A recipient of a to-do request to reply to the originator of 799 the request (TODO-REPLY); 801 . An originator of an existing to-do request to send a 802 cancellation notice to the attendees (TODO-CANCEL); 804 . An originator to request that a journal entry be appended to 805 one or more recipients (JOURNAL-REQUEST); 807 . A recipient of a journal request to reply to the originator 808 of the request (JOURNAL-REPLY); 810 . Originator to request busy time from one or more recipients 811 (BUSY-REQUEST); 813 . A recipient of a busy time request to reply to the originator 814 of the request with busy time intervals (BUSY-REPLY). 816 The following scenarios describe how these scheduling functions are 817 supported by this message protocol. 819 4.1 Request and reply to an event 821 Individual "A" requests a meeting between individuals "A", "B", "C" 822 and "D". Individual "B" confirms attendance to the meeting. 823 Individual "C" declines attendance. Individual "D" tentatively 824 confirms their attendance. This is sometime referred to as 825 "penciling-in" the event on a calendar. The following table 826 illustrates the sequence of messages that would be exchanged between 827 these individuals. 829 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 830 May 1, 1997 832 Action Originator Recipient 834 Initiate a meeting "A" sends EVENT-REQUEST 835 request message to "B" and "C" 837 Accept the meeting "B" sends EVENT-REPLY 838 request message to "A" with 839 it's ATTENDEE/STATUS 840 property parameter set 841 to "ACCEPTED" 843 Decline the meeting "C" sends EVENT-REPLY 844 request message to "A" with 845 it's ATTENDEE/STATUS 846 property parameter set 847 to "DECLINED" 849 Tentatively accept the "D" sends EVENT-REPLY 850 meeting request message to "A" with 851 it's ATTENEE/STATUS 852 property parameter set 853 to "TENTATIVE" 855 Confirm meeting status "A" sends EVENT-REPLACE 856 with attendees message to "B" and "C" 857 with current 858 information for event. 859 SEQUENCE property is 860 "1". 862 4.2 Cancel an event 864 Individual "A" requests a meeting between individuals "A", "B" and 865 "C". Individual "B" declines attendance to the meeting. Individual 866 "A" decides to cancel the meeting. The following table illustrates 867 the sequence of messages that would be exchanged between these 868 individuals. 870 Messages related to a previously canceled event or to-do must be 871 ignored. 873 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 874 May 1, 1997 876 Action Originator Recipient 878 Initiate a meeting "A" sends EVENT-REQUEST 879 request message to "B" and "C" 881 Decline the meeting "B" sends EVENT-REPLY 882 request message to "A" with 883 it's ATTENDEE/STATUS 884 property parameter set 885 to "DECLINED". 887 "C" may or may not 888 reply to the EVENT- 889 REQUEST message. 891 Cancel the meeting "A" sends EVENT-CANCEL 892 message to "B" and "C" 893 to cancel the meeting. 894 SEQUENCE parameter is 895 "1". 897 The cancelation of a to-do is achieved in a manner similar to this. 899 4.3 Request and reply to a to-do 901 Individual "A" assigns a to-do to individual "B". Individual "B" 902 accepts the to-do. Subsequently, individual "B" replies to individual 903 "A" that the to-do is completed. The following table illustrates the 904 sequence of messages that would be exchanged between these 905 individuals. 907 The request and reply of a journal entry operates similar to this 908 also. 910 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 911 May 1, 1997 913 Action Originator Recipient 915 Assign a to-do "A" sends TODO-REQUEST 916 message to "B". 918 Accept the to-do "B" sends TODO-REPLY 919 message to "A" with 920 it's ATTENDEE/STATUS 921 property parameter set 922 to "ACCEPTED" 924 Reply when to-do is "B" sends TODO-REPLY 925 completed message to "A" with 926 it's ATTENDEE/STATUS 927 property parameter set 928 to "COMPLETED". 929 RESPONSE-SEQUENCE 930 property is "1" 932 A similar set of messages could have been exchanged to assign a to-do 933 to a group of individuals. 935 4.4 Negotiate an alternate event definition 937 Individual "A" requests a meeting between individuals "A", "B" and 938 "C". Individual "B" confirms attendance to the meeting. Individual 939 "C" sends individual "A" a counter proposal for the meeting. 940 Individual "A" accepts the counter proposal. Individual "C" confirms 941 attendance to the meeting. Individual "B" accepts the modified 942 meeting request. Individual "A" distributes the revised meeting 943 details and attendees status. The following table illustrates the 944 sequence of messages that would be exchanged between these 945 individuals. 947 Action Originator Recipient 949 Initiate a meeting "A" sends EVENT-REQUEST 950 request message to "B" and "C" 952 Accept the meeting "B" sends EVENT-REPLY 953 request message to "A" with 954 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 955 May 1, 1997 957 it's ATTENDEE/STATUS 958 property parameter set 959 to "ACCEPTED" 961 Counter proposal for "C" sends EVENT-COUNTER 962 the meeting request message to "A" 963 signaling a request to 964 revise some detail 965 about the request 967 Accept the counter "A" sends EVENT-REPLACE 968 proposal message to "B" and "C". 969 SEQUENCE parameter is 970 "1". The STATUS 971 parameter on all 972 ATTENDEE properties 973 MUST be reset to "NEEDS 974 ACTION". 976 Confirm revised meeting "C" sends EVENT-REPLY 977 request message to "A" with 978 it's ATTENDEE/STATUS 979 property parameter set 980 to "ACCEPTED". 981 RESPONSE-SEQUENCE 982 parameter is "0" and 983 SEQUENCE parameter is 984 "1". 986 "B" sends EVENT-REPLY 987 message to "A" with 988 it's ATTENDEE/STATUS 989 property parameter set 990 to "ACCEPTED". 991 RESPONSE-SEQUENCE 992 parameter is "0" and 993 SEQUENCE parameter is 994 "1". 996 Confirm meeting details "A" sends a second 997 and status to attendees EVENT-REPLACE message 998 to "B" and "C" with 999 current information for 1000 event. SEQUENCE 1001 property is "2". 1003 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1004 May 1, 1997 1006 Individual "A" could have declined the counter proposal for the 1007 meeting request with the EVENT-DECLINE-COUNTER message. Individual 1008 "B" could have declined attendance at the meeting with the EVENT- 1009 REPLY message or delegated the original meeting request with a 1010 combination of the EVENT-REPLY to the originator and the EVENT- 1011 DELEGATE to the delegated individual (e.g., Individual "D", sometimes 1012 called "delegatee".). 1014 4.5 Delegate an event to another individual 1016 Individual "A" requests a meeting between individuals "A" and "B". 1017 Individual "B" delegates attendance to the meeting to individual "C". 1018 Individual "C" confirms attendance to the meeting. Individual "A" 1019 distributes the revised meeting details and attendee status. The 1020 following table illustrates the sequence of messages that would be 1021 exchanged between these individuals. 1023 Action Originator Recipient 1025 Initiate a meeting "A" sends EVENT-REQUEST 1026 request message to "B" and "C" 1028 Delegate the meeting "B" sends EVENT-REPLY 1029 request message to "A" with 1030 it's ATTENDEE/STATUS 1031 property parameter set 1032 to "DELEGATED" and an 1033 ATTENDEE property has 1034 been added to the reply 1035 for "C" with a 1036 DELEGATED-FROM property 1037 parmater set to address 1038 of "B". DELEGATED-TO 1039 property parameter for 1040 B set to address of 1041 "C". 1043 "B" sends EVENT- 1044 DELEGATE message to "C" 1045 with the original 1046 meeting request 1047 information. The 1048 ATTENDEE/STATUS 1049 property parameter for 1050 "B" has been set to 1051 "DELEGATED" and the 1052 ATTENDEE/DELEGATED-TO 1053 parameter has been set 1054 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1055 May 1, 1997 1057 to the address of "C". 1058 An ATTENDEE property 1059 has been added for "C" 1060 and the 1061 ATTENDEE/DELEGATED-FROM 1062 parameter has been set 1063 to the address of "B". 1065 Confirm meeting "C" sends EVENT-REPLY 1066 attendance message to "A" and "B" 1067 with it's 1068 ATTENDEE/STATUS 1069 property parameter set 1070 to "ACCEPTED" 1072 Redistribute meeting "A" sends EVENT-REPLACE 1073 details and status to message to "B" and "C" 1074 attendees with current 1075 information for event. 1076 SEQUENCE property is 1077 "1" 1079 Individual "C" could have declined the delegated proposal for the 1080 meeting request with the EVENT-REPLY message being sent to both "A" 1081 and "B". 1083 4.6 Request and reply for busy time 1085 Individual "A" requests busy time from individuals "B", "C" and "D". 1086 Individual "B" and "C" replies with busy time data to individual "A". 1087 Individual "D" does not support busy time requests and does not reply 1088 with any data. If the transport binding supports exception messages, 1089 then a "unsupported capability" message is returned by individual "D" 1090 to individual "A". The following table illustrates the sequence of 1091 messages that would be exchanged between these individuals. 1093 Action Originator Recipient 1095 Initiate a busy time "A" sends BUSY-REQUEST 1096 request message to "B", "C" and 1097 "D" 1098 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1099 May 1, 1997 1101 Reply to the busy time "B" and "C" sends BUSY- 1102 request with busy time REPLY message to "A" 1103 data with their busy time 1104 data. 1106 (Assuming transport "D" sends an exception 1107 supports exchange of message (i.e., 302) to 1108 exception messages) "A" 1109 Reply that busy time 1110 requests is an 1111 unsupported capability. 1113 5. Message Profile Specifications 1115 This section specifies the individual message formats defined by this 1116 design document. It is heavily based on the [ICAL] and [ID-CSP] 1117 documents. The message formats also borrow from the on-going 1118 discussions within the IETF Calendaring and Scheduling Working Group. 1120 Each individual message format is identified by the value of the 1121 PROFILE calendar property. If a [ICAL] defined property is not 1122 specified in an individual message format, then it is not allowed in 1123 the message type. 1125 Each message type provides support for a specific scheduling 1126 function. Taken as a whole, these message types provide support for a 1127 robust level of calendaring and scheduling functionality. These 1128 message types are summarized in the following table. Only the 1129 following message types are supported by this usage profile. 1131 Profile Parameter Description 1132 Value 1134 EVENT-REQUEST Make a request for an 1135 event 1137 EVENT-REPLY Reply to an event 1138 request 1140 EVENT-CANCEL Cancel an existing 1141 event request 1142 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1143 May 1, 1997 1145 EVENT-REPLACE Replace the current 1146 event request with a 1147 complete set of 1148 properties 1150 EVENT-DELEGATE Delegate an existing 1151 event request 1153 EVENT-COUNTER Make a counter proposal 1154 to the event request 1156 EVENT-DECLINECOUNTER Decline the counter 1157 proposal to the event 1158 request 1160 TODO-REQUEST Assign a to-do 1162 TODO-REPLY Reply to a to-do 1163 assignment 1165 TODO-CANCEL Cancel an existing to- 1166 do request. 1168 JOURNAL-REQUEST Request that a a 1169 journal entry gets 1170 appended to a calendar 1171 date. 1173 JOURNAL-REPLY Reply to a journal 1174 request. 1176 BUSY-REQUEST Request free or busy 1177 time data 1179 BUSY-REPLY Reply to a free/busy 1180 time request 1181 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1182 May 1, 1997 1184 6. Message Types 1186 This design document is meant to serve as the basis for implementing 1187 a message-based scheduling function within calendaring and scheduling 1188 products. In order to meet this goal, a common set of message-based 1189 scheduling semantics or functionality needs to be defined. The 1190 messages defined in this section provide such a set of semantics. 1192 The message definitions do not include a binding to the MIME email 1193 transport. This information is provided in a subsequent section of 1194 this document. 1196 In the following tables, the properties are classified as either 1197 ALWAYS (i.e., "A"), EXCLUDED (i.e., "X") or SOMETIMES (i.e., "S"). 1198 Additionally, the values for the properties may be constrained; as 1199 indicated in the descriptive text for that property. Properties 1200 classified as ALWAYS MUST appear within instances of the message 1201 type. Properties classified as EXCLUDED MUST NOT appear within 1202 instances of the message type. Properties classified as SOMETIMES MAY 1203 appear within instances of the message type. 1205 Implementations conforming to this document MUST be able to parse, 1206 and store for possible forwarding, all properties classified as 1207 ALWAYS and SOMETIMES.. 1209 6.1 EVENT-REQUEST 1211 This message type is used to request a new event with a one or more 1212 people. The message is sent from an originator (i.e., ROLE=OWNER or 1213 ORGANIZER) of an event request to one or more intended recipients 1214 (i.e., ROLE=ATTENDEE). The originator MUST be either the OWNER or 1215 ORGANIZER of the event. 1217 This message MUST not be used to reschedule an event. The EVENT- 1218 REPLACE or a sequence of the EVENT-CANCEL followed by the EVENT- 1219 REQUEST profile types MUST be used by the originator to change or 1220 reschedule this event. 1222 If an Alarm is specified in an EVENT-REQUEST, it is only specified as 1223 a suggestion. A recipient may ignore the Alarm component entirely. A 1224 recipient is not obligated to use any information defined in the 1225 Alarm component. However, the recipient should forward all alarm 1226 information in a delegated request. 1228 EVENT-REQUEST 1230 Calendar Properties 1232 GEO S 1234 PRODID A 1235 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1236 May 1, 1997 1238 VERSION A, Value must be "2.0". 1240 PROFILE A,"EVENT-REQUEST" 1242 PROFILE- A, Value must be "0.9". 1243 VERSION 1245 Timezone Component Properties 1247 COMMENT X 1249 CREATED S 1251 DAYLIGHT S 1253 DTSTART A 1255 DTEND S 1257 RDATE S, Either RDATE or RRULE may 1258 be specified, but not both. 1260 RRULE S, Either RDATE or RRULE may 1261 be specified, but not both. 1263 TZNAME S 1265 TZOFFSET A 1267 TZTRANS S 1269 UID S 1271 Event Component Properties 1273 ATTACH S, "VALUE=URL" only. 1275 ATTENDEE A, Value is an RFC822 mailbox 1276 address for C&S capability. 1277 STATUS parameter is either 1278 absent or has value "NEEDS 1279 ACTION". 1281 CATEGORIES S 1283 CLASS S 1285 CREATED S 1287 COMPLETED X 1289 DESCRIPTION A, Value may be NULL text. 1291 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1292 May 1, 1997 1294 DUE X 1296 DURATION X 1298 DTEND A, Must be a date/time after 1299 DTSTART. May span date 1300 boundary. 1302 DTSTART A 1304 EXDATE S, See issues list. 1306 EXRULE S, See issues list. 1308 LAST-MODIFIED S 1310 LOCATION S 1312 PRIORITY X 1314 RELATED-TO S 1316 REQUEST-REPLY X 1318 RDATE S, See issues list. 1320 RRULE S, See issues list. 1322 RESOURCES S 1324 RESPONSE- X 1325 SEQUENCE 1327 SEQUENCE A, If not zero 1329 STATUS S, Value only one of TENTATIVE 1330 | ACCEPTED. This property is 1331 used by the originator to 1332 indicate the consensus for the 1333 meeting, not a status on any 1334 of the attendees. 1336 SUMMARY S, May be NULL text. 1338 TRANSP X 1340 URL S 1342 UID A, Must be maintained by the 1343 recipients. 1345 To-do Component Properties 1346 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1347 May 1, 1997 1349 To-do component is excluded 1350 from this message type. 1352 Journal Component Properties 1354 Journal component is excluded 1355 from this message type. 1357 Alarm Component Properties 1359 ATTACH S 1361 CATEGORIES A, If an alarm is specified 1363 CREATED S 1365 DESCRIPTION S 1367 DTSTART A, If an alarm is specified 1369 DURATION A, If an alarm is specified 1371 LAST-MODIFIED S 1373 RELATED-TO S 1375 REPEAT A, If an alarm is specified 1377 SUMMARY S 1379 URL S 1381 Freebusy Component Properties 1383 Freebusy component is excluded 1384 from this message type. 1386 Non-standard Properties 1388 X-token S, but recipient may choose to 1389 ignore those non-standard 1390 properties, specified as 1391 optional. 1393 6.2 EVENT-REPLY 1395 The message is used to RSVP to an existing event request. The message 1396 is sent from a recipient of an event request back to the event 1397 ORGANIZER. If an ORGANIZER is not specified on the request, then the 1398 message is sent to the OWNER. The message is only used to change the 1399 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1400 May 1, 1997 1402 attendee's status from NEEDS ACTION, the default, to either ACCEPTED, 1403 DECLINED, TENTATIVE, or DELEGATED. The message may also be used by an 1404 attendee to later change their status back to some other value. 1406 Recipients may end up sending numerous EVENT-REPLY messages to change 1407 their attendance status from one value to another. Individual reply 1408 messages will have a RESPONSE-SEQUENCE property with a value that is 1409 incremented for each reply sequence. The first reply has a RESPONSE- 1410 SEQUENCE value of "0"; the second a value of "1", etc. 1412 This message type is not used to make a counter proposal to an event 1413 request. This would be accomplished by sending an EVENT-COUNTER 1414 message to the ORGANIZER of the original event. If an ORGANIZER is 1415 not specified on the request, then the message is sent to the OWNER. 1416 The UID of the original event request is used as the primary key for 1417 the event that is being replied to. 1419 An EVENT-REPLY to a recurring event can confirm, tentatively confirm 1420 or decline the whole event request or individual instances of a 1421 recurrence sequence. 1423 EVENT-REPLY 1425 Calendar Properties 1427 GEO S 1429 PRODID A 1431 VERSION A, Value must be "2.0". 1433 PROFILE A,"EVENT-REPLY" 1435 PROFILE- A, Value must be "0.9". 1436 VERSION 1438 Timezone Component Properties 1440 Timezone component is excluded 1441 from this message type. 1443 Event Component Properties 1445 ATTACH X 1447 ATTENDEE A, Value is an RFC822 mailbox 1448 address for C&S capability. 1449 Must be the address of the 1450 recipient replying. 1452 CATEGORIES X 1453 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1454 May 1, 1997 1456 CLASS X 1458 COMMENT Text value. Provides a comment 1459 from the recipient to the 1460 originator about the reply. 1461 For example, "I can't travel 1462 this far for a meeting." 1464 CREATED X 1466 COMPLETED X 1468 DESCRIPTION X 1470 DUE X 1472 DURATION X 1474 DTEND X 1476 DTSTART X 1478 EXDATE S, See issues list. Specifies 1479 the dates that are exceptions 1480 to the status update. 1482 EXRULE S, See issues list. Specifies 1483 the rule that defines the 1484 exceptions to the status 1485 update. 1487 LAST-MODIFIED X 1489 LOCATION X 1491 PRIORITY X 1493 RELATED-TO X 1495 REQUEST- Any of the values defined in 1496 STATUS the table below. 1498 RDATE X 1500 RRULE X 1502 RESOURCES X 1504 RESPONSE- A, If not zero. 1505 SEQUENCE 1507 SEQUENCE A, If not zero 1508 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1509 May 1, 1997 1511 STATUS X Status for attendee must be 1512 specified in STATUS parameter 1513 of ATTENDEE property. 1515 SUMMARY X 1517 TRANSP X 1519 URL X 1521 UID A, Must be the UID of the 1522 EVENT-REQUEST associate with 1523 the reply. 1525 To-do Component Properties 1527 To-do component is excluded 1528 from this message type. 1530 Journal Component Properties 1532 Journal component is excluded 1533 from this message type. 1535 Alarm Component Properties 1537 Alarm component is excluded 1538 from this message type. 1540 Freebusy Properties 1542 Freebusy component is excluded 1543 from this message type. 1545 Non-Standard Properties 1547 X-token S, But recipient may choose to 1548 ignore those non-standard 1549 properties, specified as 1550 optional. 1552 The REQUEST-STATUS property may include the following values: 1554 Short Return Longer Return Status Offending Data 1555 Status Description 1557 0 Success. None. 1559 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1560 May 1, 1997 1562 10 Success, but fallback Property name and value 1563 taken on one or more may be specified. 1564 property values. 1566 11 Success, invalid Property name may be 1567 property ignored. specified. 1569 12 Success, invalid Property parameter name 1570 property parameter and value may be 1571 ignored. specified. 1573 13 Success, unknown non- Non-standard property 1574 standard property name may be specified. 1575 ignored. 1577 14 Success, unknown non- 1578 standard property value standard value may be Property and non- 1579 ignored. specified. 1581 15 Success, invalid Calendar component 1582 calendar component sentinel (e.g., 1583 ignored. "BEGIN:ALARM") may be 1584 specified. 1586 16 Success, request Original and forwarded 1587 forwarded to calendar RFC822 addresses may be 1588 user. specified. 1590 17 Success, repeating event RRULE or RDATE property 1591 ignored. Scheduled as a name and value may be 1592 single event. specified. 1594 18 Success, truncated end DTEND property value may 1595 date/time to date be specified. 1596 boundary. 1598 100 Invalid property name. Property name may be 1599 specified. 1601 101 Invalid property value. Property name and value 1602 may be specified. 1604 102 Invalid property Property parameter name 1605 parameter. and value may be 1606 specified. 1608 103 Invalid property Property parameter name 1609 parameter value. and value may be 1610 specified. 1612 104 Invalid calendar Calendar component 1613 component sequence. sentinel may be 1614 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1615 May 1, 1997 1617 specified (e.g., 1618 BEGIN:TIMEZONE). 1620 201 Invalid date or time. Date/time value(s) may 1621 be specified. 1623 202 Invalid rule. Rule value may be 1624 specified. 1626 203 Request not supported. Profile property value 1627 may be specified. 1629 204 Invalid calendar user. Attendee property value 1630 may be specified. 1632 301 Event conflict. DTSTART and DTEND 1633 Date/time is busy. property name and values 1634 may be specified. 1636 302 Request not supported. PROFILE property value 1637 may be specified. 1639 401 Service unavailable. ATTENDEE property value 1640 may be specified. 1642 402 Invalid calendar ATTENDEE property value 1643 service. may be specified. 1645 403 Invalid calendar user. ATTENDEE property value 1646 may be specified. 1648 404 No scheduling support ATTENDEE property value 1649 for user. may be specified. 1651 405 No authority. PROFILE and ATTENDEE 1652 property values may be 1653 specified. 1655 6.3 EVENT-CANCEL 1657 This message type is used to send a cancellation notice of an 1658 existing event request to the attendees. The message is sent by the 1659 event OWNER or ORGANIZER to the recipients of the original event 1660 request. The OWNER and ORGANIZER are ROLE parameter values for the 1661 ATTENDEE property. 1663 EVENT-CANCEL 1664 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1665 May 1, 1997 1667 Calendar Properties 1669 GEO S 1671 PRODID A 1673 VERSION A, Value must be "2.0". 1675 PROFILE A,"EVENT-CANCEL" 1677 PROFILE- A, Value must be "0.9". 1678 VERSION 1680 Timezone Component Properties 1682 Timezone component is excluded 1683 from this message type. 1685 Event Component Properties 1687 ATTACH X 1689 ATTENDEE X 1691 CATEGORIES X 1693 CLASS X 1695 CREATED X 1697 COMMENT S, Text value. Provides a 1698 comment from the originator to 1699 the attendees concerning the 1700 cancellation notice. 1702 COMPLETED X 1704 DESCRIPTION X 1706 DUE X 1708 DURATION X 1710 DTEND X 1712 DTSTART X 1714 EXDATE X 1716 EXRULE X 1718 LAST-MODIFIED X 1719 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1720 May 1, 1997 1722 LOCATION X 1724 PRIORITY X 1726 RELATED-TO X 1728 REQUEST- X 1729 STATUS 1731 RDATE X 1733 RRULE X 1735 RESOURCES X 1737 RESPONSE- X 1738 SEQUENCE 1740 SEQUENCE A if not zero 1742 STATUS X 1744 SUMMARY X 1746 TRANSP X 1748 URL S 1750 UID A, Must be the UID of the 1751 original EVENT-REQUEST 1752 associated with the 1753 cancellation notice. 1755 To-do Component Properties 1757 To-do component is excluded 1758 from this message type. 1760 Journal Component Properties 1762 Journal component is excluded 1763 from this message type. 1765 Alarm Properties 1767 Alarm component is excluded 1768 from this message type. 1770 Freebusy Properties 1772 Freebusy component is excluded 1773 from this message type. 1775 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1776 May 1, 1997 1778 Non-standard Properties 1780 X-token S, But recipient may choose to 1781 ignore those non-standard 1782 properties, specified as 1783 optional. 1785 6.4 EVENT-REPLACE 1787 This message type is used reschedule an existing event or to provide 1788 attendees with an up-to-date description of the event. The message is 1789 sent from an originator (i.e., ROLE=OWNER or ORGANIZER) of an event 1790 request to one or more intended recipients. The OWNER and ORGANIZER 1791 are ROLE parameter values for the ATTENDEE property. The originator 1792 MUST be either the OWNER or ORGANIZER of the event. 1794 EVENT-REPLACE 1796 Calendar Properties 1798 GEO S 1800 PRODID A 1802 VERSION A, Value must be "2.0". 1804 PROFILE A,"EVENT-REPLACE" 1806 PROFILE- A, Value must be "0.9". 1807 VERSION 1809 Timezone Component Properties 1811 CREATED S 1813 DAYLIGHT S 1815 DTSTART A 1817 DTEND S 1819 RDATE S, Either RDATE or RRULE may 1820 be specified, but not both. 1822 RRULE S, Either RDATE or RRULE may 1823 be specified, but not both. 1825 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1826 May 1, 1997 1828 TZNAME S 1830 TZOFFSET A 1832 TZTRANS S 1834 UID S 1836 Event Component Properties 1838 ATTACH S, URL only. 1840 ATTENDEE A, Value is an RFC822 mailbox 1841 address for C&S capability. If 1842 used to reschedule an event, 1843 then the STATUS parameter must 1844 either be absent or has a 1845 value of "NEEDS ACTION". 1847 CATEGORIES S 1849 CLASS S 1851 COMMENT X 1853 CREATED S 1855 COMPLETED X 1857 DESCRIPTION A, Value may be NULL text. 1859 DUE X 1861 DURATION X 1863 DTEND A, Value is of the ISO 8601 1864 complete representation, basic 1865 format of a UTC based date and 1866 time; unless specifying a 1867 loosely coupled date and time. 1869 DTSTART A, Value is of the ISO 8601 1870 complete representation, basic 1871 format of a UTC based date and 1872 time; unless specifying a 1873 loosely coupled date and time. 1875 EXDATE S, See issues list. 1877 EXRULE S, See issues list. 1879 LAST-MODIFIED S 1880 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1881 May 1, 1997 1883 LOCATION S 1885 PRIORITY X 1887 RELATED-TO O 1889 REQUEST- X 1890 STATUS 1892 RDATE S, See issues list. 1894 RRULE S, See issues list. 1896 RESOURCES S 1898 RESPONSE- X 1899 SEQUENCE 1901 SEQUENCE A if not zero 1903 STATUS S, Value only one of TENTATIVE 1904 | ACCEPTED. This property is 1905 used by the originator to 1906 indicate the consensus for the 1907 meeting. 1909 SUMMARY S, May be NULL text. 1911 TRANSP X 1913 URL S 1915 UID A, Must be the UID of the 1916 original EVENT-REQUEST. 1918 To-do Component Properties 1920 To-do component is excluded 1921 from this message type. 1923 Journal Component Properties 1925 Journal component is excluded 1926 from this message type. 1928 Alarm Component Properties 1930 ATTACH S 1932 CATEGORIES A, If an alarm is specified 1934 CREATED S 1935 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1936 May 1, 1997 1938 DESCRIPTION S 1940 DTSTART A, If an alarm is specified 1942 DURATION A, If an alarm is specified 1944 LAST-MODIFIED S 1946 RELATED-TO S 1948 REPEAT A, If an alarm is specified 1950 SUMMARY S 1952 URL S 1954 Freebusy Component Properties 1956 Freebusy component is excluded 1957 from this message type. 1959 Non-standard Properties 1961 X-token S, but recipient may choose to 1962 ignore those non-standard 1963 properties, specified as 1964 optional. 1966 6.5 EVENT-COUNTER 1968 This message type is used by a recipient of an event request to issue 1969 a counter-proposal to the event. The message is sent from a recipient 1970 of an existing event request to the OWNER and/or ORGANIZER of the 1971 original event request. The OWNER and ORGANIZER are ROLE parameter 1972 values for the ATTENDEE property. 1974 Alternative counter proposals are not supported. That is, multiple 1975 VEVENT calendar components similar to that allowed in the EVENT-REPLY 1976 are not allowed in this message type. 1978 The EVENT-COUNTER message must include a complete description of the 1979 event. 1981 EVENT-COUNTER 1983 Calendar Properties 1984 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 1985 May 1, 1997 1987 GEO S 1989 PRODID A 1991 VERSION A, Value must be "2.0". 1993 PROFILE A,"EVENT-COUNTER" 1995 PROFILE- A, Value must be "0.9". 1996 VERSION 1998 Timezone Component Properties 2000 CREATED S 2002 DAYLIGHT S 2004 DTSTART A 2006 DTEND S 2008 RDATE S, Either RDATE or RRULE may 2009 be specified, but not both. 2011 RRULE S, Either RDATE or RRULE may 2012 be specified, but not both. 2014 TZNAME S 2016 TZOFFSET A 2018 TZTRANS S 2020 UID S 2022 Event Component Properties 2024 ATTACH S, VALUE=URL only. 2026 ATTENDEE A, Value is an RFC822 mailbox 2027 address for C&S capability. A 2028 TYPE=ROOM parameter value pair 2029 supported. Property can be 2030 used to propose other 2031 attendees. 2033 CATEGORIES S 2035 CLASS S 2037 COMMENT A, Text value. Provides a 2038 comment from the recipient to 2039 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2040 May 1, 1997 2042 the originator about the 2043 counter proposal. For example, 2044 "How about my place instead of 2045 yours". 2047 CREATED X 2049 COMPLETED X 2051 DESCRIPTION A, Value may be NULL text. 2053 DUE X 2055 DURATION X 2057 DTEND A, Value is of the ISO 8601 2058 complete representation, basic 2059 format of a UTC based date and 2060 time; unless specifying a 2061 loosely coupled date and time. 2063 DTSTART S, Value is of the ISO 8601 2064 complete representation, basic 2065 format of a UTC based date and 2066 time; unless specifying a 2067 loosely coupled date and time. 2069 EXDATE S, See issues list. 2071 EXRULE S, See issues list. 2073 LAST-MODIFIED X 2075 LOCATION S 2077 RNUM X 2079 PRIORITY X 2081 RELATED-TO S 2083 REQUEST- X 2084 STATUS 2086 RDATE S, See issues list. 2088 RRULE S, See issues list. 2090 RESOURCES S 2092 RESPONSE- A, If not zero 2093 SEQUENCE 2094 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2095 May 1, 1997 2097 SEQUENCE A, If not zero 2099 STATUS X 2101 SUMMARY S, May be NULL text. 2103 TRANSP X 2105 URL S 2107 UID A, Must be the value of the 2108 UID of the EVENT-REQUEST 2109 associated with the counter 2110 proposal. 2112 To-do Component Properties 2114 To-do component is excluded 2115 from this message type. 2117 Journal Component Properties 2119 Journal component is excluded 2120 from this message type. 2122 Alarm Properties 2124 Alarm component is excluded 2125 from this message type. 2127 Freebusy Properties 2129 Freebusy component is excluded 2130 from this message type. 2132 Non-standard Properties 2134 X-token S, But recipient may choose to 2135 ignore those non-standard 2136 properties, specified as 2137 optional. 2139 6.6 EVENT-DECLINECOUNTER 2141 This message type is used by the originator of an event request to 2142 decline a counter proposal. The message is sent from the OWNER and/or 2143 ORGANIZER of the original event request to the originator of the 2144 EVENT-COUNTER message. This originator of the counter proposal 2145 message should be one of the ATTENDEE in the original event request. 2147 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2148 May 1, 1997 2150 Acceptance of a counter proposal message is accomplished by the OWNER 2151 and/or ORGANIZER of the original event request sending out an EVENT- 2152 REPLACE message with the updated event description. 2154 EVENT-DECLINECOUNTER 2156 Calendar Properties 2158 GEO S 2160 PRODID A 2162 VERSION A, Value must be "2.0". 2164 PROFILE A,"EVENT-DECLINECOUNTER" 2166 PROFILE- A, Value must be "0.9". 2167 VERSION 2169 Timezone Properties 2171 Timezone component is excluded 2172 from this message type. 2174 Event Component Properties 2176 ATTACH X 2178 ATTENDEE S, Value is an RFC822 mailbox 2179 address for C&S capability. 2180 Address corresponds to the 2181 originator (i.e., ATTENDEE 2182 value) of the counter proposal 2183 message. 2185 CATEGORIES X 2187 CLASS X 2189 COMMENT S, Text value. Provides a 2190 comment from the originator to 2191 the recipient about the 2192 decline of the counter 2193 proposal. For example, "We are 2194 unable to change the meeting 2195 time or place". 2197 CREATED X 2199 COMPLETED X 2200 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2201 May 1, 1997 2203 DESCRIPTION X 2205 DUE X 2207 DURATION X 2209 DTEND X 2211 DTSTART X 2213 EXDATE X 2215 EXRULE X 2217 LAST-MODIFIED X 2219 LOCATION S 2221 PRIORITY X 2223 RELATED-TO S 2225 REQUEST- S, One of the values from the 2226 STATUS table below. 2228 RDATE X 2230 RRULE X 2232 RESOURCES X 2234 RESPONSE- A, Must be the same as that 2235 SEQUENCE specified in the EVENT- 2236 COUNTER. 2238 SEQUENCE A, Must be the same as that 2239 specified in the EVENT- 2240 COUNTER. 2242 STATUS X 2244 SUMMARY X 2246 TRANSP X 2248 URL S 2250 UID A, Must be the value of the 2251 UID of the original EVENT- 2252 REQUEST referenced in the 2253 counter proposal. 2255 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2256 May 1, 1997 2258 To-do Component Properties 2260 To-do component is excluded 2261 from this message type. 2263 Journal Component Properties 2265 Journal component is excluded 2266 from this message type. 2268 Alarm Component Properties 2270 Alarm component is excluded 2271 from this message type. 2273 Freebusy Properties 2275 Freebusy component is excluded 2276 from this message type. 2278 Non-standard Properties 2280 X-token S, but recipient may choose to 2281 ignore those non-standard 2282 properties, specified as 2283 optional. 2285 The REQUEST-STATUS property may include the following values: 2287 Short Return Longer Return Status Offending Data 2288 Status Description 2290 0 Success. None. 2292 10 Success, but fallback Property name and value 2293 taken on one or more may be specified. 2294 property values. 2296 11 Success, invalid Property name may be 2297 property ignored. specified. 2299 12 Success, invalid Property parameter name 2300 property parameter and value may be 2301 ignored. specified. 2303 13 Success, unknown non- Non-standard property 2304 standard property name may be specified. 2306 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2307 May 1, 1997 2309 ignored. 2311 14 Success, unknown non- Property and non- 2312 standard property value standard value may be 2313 ignored. specified. 2315 15 Success, invalid 2316 calendar component sentinel (e.g., Calendar component 2317 ignored. "BEGIN:ALARM") may be 2318 specified. 2320 16 Success, request 2321 forwarded to calendar RFC822 addresses may be Original and forwarded 2322 user. specified. 2324 17 Success, repeating event RRULE or RDATE property 2325 ignored. Scheduled as a name and value may be 2326 single event. specified. 2328 18 Success, truncated end DTEND property value may 2329 date/time to date be specified. 2330 boundary. 2332 100 Invalid property name. Property name may be 2333 specified. 2335 101 Invalid property value. Property name and value 2336 may be specified. 2338 102 Invalid property Property parameter name 2339 parameter. and value may be 2340 specified. 2342 103 Invalid property Property parameter name 2343 parameter value. and value may be 2344 specified. 2346 104 Invalid calendar Calendar component 2347 component sequence. sentinel may be 2348 specified (e.g., 2349 BEGIN:TIMEZONE). 2351 201 Invalid date or time. Date/time value(s) may 2352 be specified. 2354 202 Invalid rule. Rule value may be 2355 specified. 2357 203 Request not supported. Profile property value 2358 may be specified. 2360 204 Invalid calendar user. Attendee property value 2361 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2362 May 1, 1997 2364 may be specified. 2366 301 Event conflict. DTSTART and DTEND 2367 Date/time is busy. property name and values 2368 may be specified. 2370 302 Request not supported. PROFILE property value 2371 may be specified. 2373 401 Service unavailable. ATTENDEE property value 2374 may be specified. 2376 402 Invalid calendar ATTENDEE property value 2377 service. may be specified. 2379 403 Invalid calendar user. ATTENDEE property value 2380 may be specified. 2382 404 No scheduling support ATTENDEE property value 2383 for user. may be specified. 2385 405 No authority. PROFILE and ATTENDEE 2386 property values may be 2387 specified. 2389 6.7 EVENT-DELEGATE 2391 This message type is used to delegate an event request to an another 2392 individual. The message is sent by one of the attendees of an 2393 existing event request to some other individual. 2395 The message type MAY only be sent by one of the attendees of an 2396 existing event request. The properties from the original event 2397 request MUST be included in the calendar component to assure that the 2398 delegated attendee has a complete specification of the delegated 2399 event. This MAY include a description that reflects numerous 2400 revisions of the original request. The message must also contain a 2401 new ATTENDEE property corresponding to the individual being delegated 2402 to. 2404 An EVENT-REPLY message is also sent from the recipient delegating the 2405 request to the originator of the event request; indicating that the 2406 original request is being delegated. 2408 The EVENT-DELEGATE message must assign the values of the RSVP and 2409 EXPECT property parameters associated with the recipient delegating 2410 the request to the ATTENDEE property of the delegate. 2412 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2413 May 1, 1997 2415 EVENT-DELEGATE 2417 Calendar Properties 2419 GEO S 2421 PRODID A 2423 VERSION A, Value must be "2.0". 2425 PROFILE A,"EVENT-DELEGATE" 2427 PROFILE- A, Value must be "0.9". 2428 VERSION 2430 Timezone Component Properties 2432 CREATED S 2434 DAYLIGHT S 2436 DTSTART A 2438 DTEND S 2440 RDATE S, Either RDATE or RRULE may 2441 be specified, but not both. 2443 RRULE S, Either RDATE or RRULE may 2444 be specified, but not both. 2446 TZNAME S 2448 TZOFFSET A 2450 TZTRANS S 2452 UID S 2454 Event Component Properties 2456 ATTACH S, VALUE=URL only. 2458 ATTENDEE A, Value is an RFC822 mailbox 2459 address for C&S capability. A 2460 new ATTENDEE property MUST be 2461 included; corresponding to the 2462 delegated individual. This 2463 property should include the 2464 DELEGATED-FROM property 2465 parameter. The ATTENDEE 2466 property must also have the 2467 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2468 May 1, 1997 2470 same RSVP and EXPECT property 2471 parameter values as the 2472 recipient delegating the 2473 request. The STATUS parameter 2474 for this individual is either 2475 absent or has a value of 2476 "NEEDS ACTION". The ATTENDEE 2477 property associated with the 2478 recipient delegating the 2479 request should include the 2480 DELEGATED-TO property 2481 parameter. 2483 CATEGORIES S 2485 CLASS S 2487 CREATED S 2489 COMMENT S, Text value. Provides a 2490 comment from the originator of 2491 the delegate message to the 2492 delegated individual 2493 concerning the delegated 2494 event. 2496 COMPLETED X 2498 DESCRIPTION A, Value may be NULL text. 2500 DUE X 2502 DURATION X 2504 DTEND A, Value is of the ISO 8601 2505 complete representation, basic 2506 format of a UTC based date and 2507 time; unless specifying a 2508 loosely coupled date and time. 2510 DTSTART A, Value is of the ISO 8601 2511 complete representation, basic 2512 format of a UTC based date and 2513 time; unless specifying a 2514 loosely coupled date and time. 2516 EXDATE S, See issues list. 2518 EXRULE S, See issues list. 2520 LAST-MODIFIED S 2521 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2522 May 1, 1997 2524 LOCATION S 2526 PRIORITY X 2528 RELATED-TO S 2530 REQUEST- X 2531 STATUS 2533 RDATE S, See issues list. 2535 RRULE S, See issues list. 2537 RESOURCES S 2539 RESPONSE- X, This message not to be used 2540 SEQUENCE for "rescheduling" an event. 2542 SEQUENCE A if not zero 2544 STATUS S, Value only one of TENTATIVE 2545 | ACCEPTED. This property is 2546 used to convey the consensus 2547 for the meeting. 2549 SUMMARY S, May be Null text. 2551 TRANSP X 2553 URL S 2555 UID A, Must be the UID of the 2556 original EVENT-REQUEST. 2558 To-do Component Properties 2560 To-do component is excluded 2561 from this message type. 2563 Journal Component Properties 2565 Journal component is excluded 2566 from this message type. 2568 Alarm Component Properties 2570 ATTACH S 2572 CATEGORIES A, If an alarm is specified 2574 CREATED S 2575 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2576 May 1, 1997 2578 DESCRIPTION S 2580 DTSTART A, If an alarm is specified 2582 DURATION A, If an alarm is specified 2584 LAST-MODIFIED S 2586 RELATED-TO S 2588 REPEAT A, If an alarm is specified 2590 SUMMARY S 2592 URL S 2594 Freebusy Component Properties 2596 Freebusy component is excluded 2597 from this message type. 2599 Non-standard Properties 2601 X-token S, but recipient may choose to 2602 ignore those non-standard 2603 properties, specified as 2604 optional. 2606 6.8 TODO-REQUEST 2608 This message type is used to send an assignment of a to-do or action 2609 item to one or more recipients. The message is sent from an 2610 originator (i.e., ROLE=OWNER or ORGANIZER) of a to-do request to one 2611 or more intended recipients (ROLE=ATTENDEE). The OWNER and OGANIZER 2612 are ROLE parameter values for the ATTENDEE property. 2614 A to-do may be defined as a recurring action item. 2616 This usage profile does not provide support the capability to 2617 redefine a to-do, other than by canceling and assigning a newly 2618 defined to-do. 2620 TODO-REQUEST 2622 Calendar Properties 2624 GEO S 2625 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2626 May 1, 1997 2628 PRODID A 2630 VERSION A, Value must be "2.0". 2632 PROFILE A,"TODO-REQUEST" 2634 PROFILE- A, Value must be "0.9". 2635 VERSION 2637 Timezone Component Properties 2639 CREATED S 2641 DAYLIGHT S 2643 DTSTART A 2645 DTEND S 2647 RDATE S, Either RDATE or RRULE may 2648 be specified, but not both. 2650 RRULE S, Either RDATE or RRULE may 2651 be specified, but not both. 2653 TZNAME S 2655 TZOFFSET A 2657 TZTRANS S 2659 UID S 2661 Event Component Properties 2663 Event component is excluded 2664 from this message type. 2666 To-do Component Properties 2668 ATTACH S, VALUE=URL only. 2670 ATTENDEE A, Value is an RFC822 mailbox 2671 address for C&S capability. 2672 STATUS parameter is either 2673 absent or has a value "NEED 2674 ACTION". 2676 CATEGORIES S 2678 CLASS S 2679 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2680 May 1, 1997 2682 COMMENT S 2684 CREATED S 2686 COMPLETED X 2688 DESCRIPTION A, Value may be NULL text. 2690 DUE A, Value is of the ISO 8601 2691 complete representation, basic 2692 format of a UTC based date and 2693 time. This is the date and 2694 time that the to-do is to be 2695 completed; unless specifying a 2696 loosely coupled date and time. 2698 DURATION X 2700 DTEND X 2702 DTSTART A, Value is of the ISO 8601 2703 complete representation, basic 2704 format of a UTC based date and 2705 time. This is the date that 2706 the to-do is to first appear 2707 on the calendar; unless 2708 specifying a loosely coupled 2709 date and time. 2711 EXDATE S, See issues list. 2713 EXRULE S, See issues list. 2715 LAST-MODIFIED S 2717 LOCATION X 2719 PRIORITY A, Value must be a numeric 2720 character representing an 2721 integer. "0" indicates not 2722 set. "1", "2", "3" indicate 2723 high, medium, and low 2724 priority, respectively. 2726 RELATED-TO S 2728 REQUEST- X 2729 STATUS 2731 RDATE S, See issues list. 2733 RRULE S, See issues list. 2735 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2736 May 1, 1997 2738 RESOURCES S 2740 RESPONSE- X, This message is not used 2741 SEQUENCE for "redefining" a to-do. 2743 SEQUENCE A if not zero 2745 STATUS X 2747 SUMMARY S, May be Null text. 2749 TRANSP X 2751 URL S 2753 UID A, Must be maintained by the 2754 recipient. 2756 Journal Component Properties 2758 Journal component is excluded 2759 from this message type. 2761 Alarm Component Properties 2763 ATTACH S 2765 CATEGORIES A, If an alarm is specified 2767 CREATED S 2769 DESCRIPTION S 2771 DTSTART A, If an alarm is specified 2773 DURATION A, If an alarm is specified 2775 LAST-MODIFIED S 2777 RELATED-TO S 2779 REPEAT A, If an alarm is specified 2781 SUMMARY S 2783 URL S 2785 Freebusy Component Properties 2787 Freebusy component is excluded 2788 from this message type. 2790 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2791 May 1, 1997 2793 Non-standard Properties 2795 X-token S, but recipient may choose to 2796 ignore those non-standard 2797 properties, specified as 2798 optional. 2800 6.9 TODO-REPLY 2802 This message type is used to reply to a to-do assignment in order to 2803 update the status and possibly the completion date of the to-do. The 2804 message is sent from a recipient of a to-do request back to the to-do 2805 ORGANIZER. If an ORGANIZER is not specified on the request, then the 2806 message is sent to the OWNER. 2808 This profile is ONLY USED to reply to an to-do request; in order to 2809 ACCEPT or DECLINE a to-do. It is also be used by the recipient of a 2810 TODO-REQUEST in order to confirm completion of the to-do (i.e., 2811 ATTENDEE;STATUS=COMPLETED:.., COMPLETED=date and time of completion). 2813 TODO-REPLY 2815 Calendar Properties 2817 GEO S 2819 PRODID A 2821 VERSION A, Value must be "2.0". 2823 PROFILE A,"TODO-REPLY" 2825 PROFILE- A, Value must be "0.9". 2826 VERSION 2828 Timezone Component Properties 2830 Timezone component is excluded 2831 from this message type. 2833 Event Component Properties 2835 Event component is excluded 2836 from this message type. 2838 To-do Component Properties 2839 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2840 May 1, 1997 2842 ATTACH X 2844 ATTENDEE A, Value is an RFC822 mailbox 2845 address for C&S capability. 2846 STATUS parameter MUST be 2847 either ACCEPT or DECLINE or 2848 COMPLETED. 2850 CATEGORIES X 2852 CLASS X 2854 COMMENT S, Text value. Provides a 2855 comment from the originator of 2856 the reply to the attendees 2857 concerning the to-do reply 2858 notice. 2860 CREATED X 2862 COMPLETED A, if a TODO-REPLY to indicate 2863 completion of a task. Value is 2864 of the ISO 8601 complete 2865 representation, basic format 2866 of a UTC based date and time. 2867 This is the time the task was 2868 completed. 2870 DESCRIPTION X 2872 DUE X 2874 DURATION X 2876 DTEND X 2878 DTSTART X 2880 EXDATE X 2882 EXRULE X 2884 LAST-MODIFIED X 2886 LOCATION X 2888 PRIORITY X 2890 RELATED-TO X 2892 REQUEST- A, One of the value from the 2893 STATUS table below. 2895 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2896 May 1, 1997 2898 RDATE X 2900 RRULE X 2902 RESOURCES X 2904 RESPONSE- A if not zero 2905 SEQUENCE 2907 SEQUENCE A if not zero 2909 STATUS S, Value may only be NEEDS 2910 ACTION or COMPLETED. This 2911 property is used to confirm to 2912 the originator the status of 2913 the to-do. 2915 SUMMARY X 2917 TRANSP X 2919 URL S 2921 UID A, Must be the UID of the 2922 TODO-REQUEST associated with 2923 the reply. 2925 Journal Component Properties 2927 Journal component is excluded 2928 from this message type. 2930 Alarm Component Properties 2932 Alarm component is excluded 2933 from this message type. 2935 Freebusy Component Properties 2937 Freebusy component is excluded 2938 from this messge type 2940 Non-standard Properties 2942 X-token S, Recipient may choose to 2943 ignore those non-standard 2944 properties, specified as 2945 optional. 2947 The REQUEST-STATUS property may include the following values: 2949 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 2950 May 1, 1997 2952 Short Return Longer Return Status Offending Data 2953 Status Description 2955 0 Success. None. 2957 10 Success, but fallback 2958 taken on one or more may be specified. Property name and value 2959 property values. 2961 11 Success, invalid Property name may be 2962 property ignored. specified. 2964 12 Success, invalid Property parameter name 2965 property parameter and value may be 2966 ignored. specified. 2968 13 Success, unknown non- Non-standard property 2969 standard property name may be specified. 2970 ignored. 2972 14 Success, unknown non- 2973 standard property value standard value may be Property and non- 2974 ignored. specified. 2976 15 Success, invalid Calendar component 2977 calendar component sentinel (e.g., 2978 ignored. "BEGIN:ALARM") may be 2979 specified. 2981 16 Success, request Original and forwarded 2982 forwarded to calendar RFC822 addresses may be 2983 user. specified. 2985 18 Success, truncated end DTEND property value may 2986 date/time to date be specified. 2987 boundary. 2989 19 Success, repeating to-do RRULE or RDATE property 2990 ignored. Scheduled as a name and value may be 2991 single to-do. specified. 2993 100 Invalid property name. Property name may be 2994 specified. 2996 101 Invalid property value. Property name and value 2997 may be specified. 2999 102 Invalid property Property parameter name 3000 parameter. and value may be 3001 specified. 3003 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3004 May 1, 1997 3006 103 Invalid property Property parameter name 3007 parameter value. and value may be 3008 specified. 3010 104 Invalid calendar Calendar component 3011 component sequence. sentinel may be 3012 specified (e.g., 3013 BEGIN:TIMEZONE). 3015 201 Invalid date or time. Date/time value(s) may 3016 be specified. 3018 202 Invalid rule. Rule value may be 3019 specified. 3021 203 Request not supported. Profile property value 3022 may be specified. 3024 204 Invalid calendar user. Attendee property value 3025 may be specified. 3027 302 Request not supported. PROFILE property value 3028 may be specified. 3030 401 Service unavailable. ATTENDEE property value 3031 may be specified. 3033 402 Invalid calendar ATTENDEE property value 3034 service. may be specified. 3036 403 Invalid calendar user. ATTENDEE property value 3037 may be specified. 3039 404 No scheduling support ATTENDEE property value 3040 for user. may be specified. 3042 405 No authority. PROFILE and ATTENDEE 3043 property values may be 3044 specified. 3046 6.10 TODO-CANCEL 3048 This message type is used to send a cancellation notice for an 3049 existing to-do request to the attendees. The message is sent by the 3050 to-do OWNER or ORGANIZER to the recipients of the original event 3051 request. The OWNER and ORGANIZER are ROLE parameter values for the 3052 ATTENDEE property. 3054 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3055 May 1, 1997 3057 TODO-CANCEL 3059 Calendar Properties 3061 GEO S 3063 PRODID A 3065 VERSION A, Value must be "2.0". 3067 PROFILE A,"EVENT-CANCEL" 3069 PROFILE- A, Value must be "0.9". 3070 VERSION 3072 Timezone Component Properties 3074 Timezone component is excluded 3075 from this message type. 3077 Event Component Properties 3079 Event component is excluded 3080 from this message type. 3082 To-do Component Properties 3084 ATTACH X 3086 ATTENDEE X 3088 CATEGORIES X 3090 CLASS X 3092 COMMENT S, Text value. Provides a 3093 comment from the originator of 3094 the reply to the attendees 3095 concerning the to-do reply 3096 notice. 3098 CREATED X 3100 COMPLETED X 3102 DESCRIPTION X 3104 DUE X 3106 DURATION X 3108 DTEND X 3109 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3110 May 1, 1997 3112 DTSTART X 3114 EXDATE X 3116 EXRULE X 3118 LAST-MODIFIED X 3120 LOCATION X 3122 PRIORITY X 3124 RELATED-TO X 3126 REQUEST- X 3127 STATUS 3129 RDATE X 3131 RRULE X 3133 RESOURCES X 3135 RESPONSE- X 3136 SEQUENCE 3138 SEQUENCE X 3140 STATUS X 3142 SUMMARY X 3144 TRANSP X 3146 URL S 3148 UID A, Must be the UID of the 3149 TODO-REQUEST associated with 3150 the cancelation notice. 3152 Journal Component Properties 3154 Journal component is excluded 3155 from this message type. 3157 Alarm Properties 3159 Alarm component is excluded 3160 from this message type. 3162 Freebusy Properties 3163 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3164 May 1, 1997 3166 Freebusy component is excluded 3167 from this message type. 3169 Non-standard Properties 3171 X-token S, But recipient may choose to 3172 ignore those non-standard 3173 properties, specified as 3174 optional. 3176 6.11 JOURNAL-REQUEST 3178 This message type is used to send a request to append a journal entry 3179 to one or more recipients. The message is sent from an originator 3180 (i.e., ROLE=OWNER or ORGANIZER) of a journal request to one or more 3181 intended recipients (ROLE=ATTENDEE). The OWNER and OGANIZER are ROLE 3182 parameter values for the ATTENDEE property. 3184 A journal may note be defined as recurring. 3186 This usage profile does not provide support the capability to cancel 3187 or redefine a journal entry. 3189 JOURNAL-REQUEST 3191 Calendar Properties 3193 GEO S 3195 PRODID A 3197 VERSION A, Value must be "2.0". 3199 PROFILE A,"TODO-REQUEST" 3201 PROFILE- A, Value must be "0.9". 3202 VERSION 3204 Timezone Component Properties 3206 CREATED S 3208 DAYLIGHT S 3210 DTSTART A 3212 DTEND S 3213 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3214 May 1, 1997 3216 RDATE S, Either RDATE or RRULE may 3217 be specified, but not both. 3219 RRULE S, Either RDATE or RRULE may 3220 be specified, but not both. 3222 TZNAME S 3224 TZOFFSET A 3226 TZTRANS S 3228 UID S 3230 Event Component Properties 3232 Event component is excluded 3233 from this message type. 3235 To-do Component Properties 3237 To-do component is excluded 3238 from this message type. 3240 Journal Component Properties 3242 ATTACH S 3244 ATTENDEE A 3246 CATEGORIES S 3248 CLASS S 3250 CREATED S 3252 DESCRIPTION A 3254 DTSTART A 3256 LAST-MODIFIED S 3258 RELATED-TO S 3260 RESPONSE S 3262 RESPONSE- S 3263 SEQUENCE 3265 UID A 3267 URL S 3268 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3269 May 1, 1997 3271 Alarm Component Properties 3273 Alarm component is excluded 3274 from this message type. 3276 Freebusy Component Properties 3278 Freebusy component is excluded 3279 from this message type. 3281 Non-standard Properties 3283 X-token S, but recipient may choose to 3284 ignore those non-standard 3285 properties, specified as 3286 optional. 3288 6.12 JOURNAL-REPLY 3290 This message type is used to reply to a journal request in order to 3291 update the recipient's acceptance of the request. The message is sent 3292 from a recipient of a journal request back to the to-do ORGANIZER. 3293 If an ORGANIZER is not specified on the request, then the message is 3294 sent to the OWNER. 3296 This profile is ONLY USED to reply to journal request; in order to 3297 ACCEPT or DECLINE it. 3299 JOURNAL-REPLY 3301 Calendar Properties 3303 GEO S 3305 PRODID A 3307 VERSION A, Value must be "2.0". 3309 PROFILE A,"TODO-REPLY" 3311 PROFILE- A, Value must be "0.9". 3312 VERSION 3314 Timezone Component Properties 3316 Timezone component is excluded 3317 from this message type. 3319 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3320 May 1, 1997 3322 Event Component Properties 3324 Event component is excluded 3325 from this message type. 3327 To-do Component Properties 3329 To-do component is excluded 3330 from this message type. 3332 Journal Component Properties 3334 ATTACH X 3336 ATTENDEE A 3338 CATEGORIES X 3340 CLASS S 3342 DESCRIPTION A 3344 DTSTART X 3346 LAST-MODIFIED X 3348 RELATED-TO X 3350 RESPONSE S 3352 RESPONSE- S 3353 SEQUENCE 3355 UID A 3357 URL X 3359 Alarm Component Properties 3361 Alarm component is excluded 3362 from this message type. 3364 Freebusy Component Properties 3366 Freebusy component is excluded 3367 from this messge type 3369 Non-standard Properties 3371 X-token S, Recipient may choose to 3372 ignore those non-standard 3373 properties, specified as 3374 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3375 May 1, 1997 3377 optional. 3379 The REQUEST-STATUS property may include the following values: 3381 Short Return Longer Return Status Offending Data 3382 Status Description 3384 0 Success. None. 3386 10 Success, but fallback Property name and value 3387 taken on one or more may be specified. 3388 property values. 3390 11 Success, invalid Property name may be 3391 property ignored. specified. 3393 12 Success, invalid Property parameter name 3394 property parameter and value may be 3395 ignored. specified. 3397 13 Success, unknown non- Non-standard property 3398 standard property name may be specified. 3399 ignored. 3401 14 Success, unknown non- Property and non- 3402 standard property value standard value may be 3403 ignored. specified. 3405 15 Success, invalid Calendar component 3406 calendar component sentinel (e.g., 3407 ignored. "BEGIN:ALARM") may be 3408 specified. 3410 16 Success, request Original and forwarded 3411 forwarded to calendar RFC822 addresses may be 3412 user. specified. 3414 100 Invalid property name. Property name may be 3415 specified. 3417 101 Invalid property value. Property name and value 3418 may be specified. 3420 102 Invalid property Property parameter name 3421 parameter. and value may be 3422 specified. 3424 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3425 May 1, 1997 3427 103 Invalid property Property parameter name 3428 parameter value. and value may be 3429 specified. 3431 104 Invalid calendar Calendar component 3432 component sequence. sentinel may be 3433 specified (e.g., 3434 BEGIN:TIMEZONE). 3436 201 Invalid date or time. Date/time value(s) may 3437 be specified. 3439 202 Invalid rule. Rule value may be 3440 specified. 3442 203 Request not supported. Profile property value 3443 may be specified. 3445 204 Invalid calendar user. Attendee property value 3446 may be specified. 3448 302 Request not supported. PROFILE property value 3449 may be specified. 3451 401 Service unavailable. ATTENDEE property value 3452 may be specified. 3454 402 Invalid calendar ATTENDEE property value 3455 service. may be specified. 3457 403 Invalid calendar user. ATTENDEE property value 3458 may be specified. 3460 404 No scheduling support ATTENDEE property value 3461 for user. may be specified. 3463 405 No authority. PROFILE and ATTENDEE 3464 property values may be 3465 specified. 3467 6.13 BUSY-REQUEST 3469 This message type is used to request a busy time from one or more 3470 people. This message only permits requests for busy time information. 3471 The message is sent from an originator (i.e., ROLE=OWNER or 3472 ORGANIZER) of an free/busy time request to one or more intended 3473 recipients (i.e., ROLE=ATTENDEE). 3475 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3476 May 1, 1997 3478 BUSY-REQUEST 3480 Calendar Properties 3482 GEO S 3484 PRODID A 3486 VERSION A, Value must be "2.0". 3488 PROFILE A,"BUSY-REQUEST" 3490 PROFILE- A, Value must be "0.9". 3491 VERSION 3493 Timezone Component Properties 3495 CREATED S 3497 DAYLIGHT S 3499 DTSTART A 3501 DTEND S 3503 RDATE S, Either RDATE or RRULE may 3504 be specified, but not both. 3506 RRULE S, Either RDATE or RRULE may 3507 be specified, but not both. 3509 TZNAME S 3511 TZOFFSET A 3513 TZTRANS S 3515 UID S 3517 Event Component Properties 3519 Event component is excluded 3520 from this message type. 3522 To-do Component Properties 3524 To-do component is excluded 3525 from this message type. 3527 Journal Component Properties 3529 Journal component is excluded 3530 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3531 May 1, 1997 3533 from this message type. 3535 Alarm Component Properties 3537 Alarm component is excluded 3538 from this message type. 3540 FreeBusy Component Properties 3542 ATTENDEE A, Value is an RFC822 mailbox 3543 address for C&S capability. An 3544 instance must be specified for 3545 the originator and the 3546 intended recipients of the 3547 request. 3549 COMMENT X 3551 CREATED X 3553 DURATION X 3555 DTEND A, This is the end of the busy 3556 time period being requested. 3558 DTSTART A, This is the start of the 3559 busy time period being 3560 requested. 3562 FREEBUSY X 3564 LAST-MODIFIED X 3566 RELATED-TO X 3568 REQUEST- X 3569 STATUS 3571 RESPONSE- X, The value will always be 3572 SEQUENCE zero. 3574 SEQUENCE X, the value will always be 3575 zero 3577 UID A, Must be referenced by the 3578 recipients in their FREEBUSY- 3579 REPLY message. 3581 URL X 3583 Non-standard Properties 3584 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3585 May 1, 1997 3587 X-token S, but recipient may choose to 3588 ignore those non-standard 3589 properties, specified as 3590 optional. 3592 6.14 BUSY-REPLY 3594 The message is used to reply to an existing busy time request. The 3595 message is sent from a recipient of a busy time request back to the 3596 request ORGANIZER. If an ORGANIZER is not specified on the busy time 3597 request, then the message is sent to the OWNER. 3599 Busy time intervals are represented by individual instances of the 3600 FREEBUSY property. There is one occurrence of the property for each 3601 busy time interval. Duplicate busy time periods should not be 3602 returned. However, two different busy time periods may overlap. 3604 The FREEBUSY property value MAY include a list of values, separated 3605 by the COMA character (ASCII decimal 44). 3607 FREEBUSY properties SHOULD be sorted such that their values are in 3608 ascending order, from the most recent to past. For example, today's 3609 busy time information SHOULD appear before yesterday's busy time 3610 information. And the busy time for this half hour SHOULD appear 3611 before the busy time for earlier today. 3613 Since events MAY span a day boundary, free busy time period MAY also 3614 span a day boundary. 3616 The busy time periods may be grouped into more than one FREEBUSY 3617 component. This capability allows busy time periods to be grouped 3618 according to some common periodicity, such as a calendar week, month, 3619 or year. In this case, each FREEBUSY component needs to include the 3620 ATTENDEE, DTSTART and DTEND properties. 3622 The ATTENDEE property must be specified in the busy time reply. The 3623 value is the fully qualified RFC 822 address of the recipient 3624 replying to the busy time request. 3626 BUSY-REPLY 3628 Calendar Properties 3630 GEO S 3632 PRODID A 3633 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3634 May 1, 1997 3636 VERSION A, Value must be "2.0". 3638 PROFILE A,"BUSY-REPLY" 3640 PROFILE- A, Value must be "0.9". 3641 VERSION 3643 Timezone Component Properties 3645 CREATED S 3647 DAYLIGHT S 3649 DTSTART A 3651 DTEND S 3653 RDATE S, Either RDATE or RRULE may 3654 be specified, but not both. 3656 RRULE S, Either RDATE or RRULE may 3657 be specified, but not both. 3659 TZNAME S 3661 TZOFFSET A 3663 TZTRANS S 3665 UID S 3667 Event Component Properties 3669 Event component is excluded 3670 from this message type. 3672 To-do Component Properties 3674 To-do component is excluded 3675 from this message type. 3677 Journal Component Properties 3679 Journal component is excluded 3680 from this message type. 3682 Alarm Component Properties 3684 Alarm component is excluded 3685 from this message type. 3687 Freebusy Component Properties 3688 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3689 May 1, 1997 3691 ATTENDEE A, Value is an RFC822 mailbox 3692 address for C&S capability. 3693 Must be the address of the 3694 recipient replying. 3696 COMMENT S, Text value. Provides a 3697 comment from the originator of 3698 the reply to the recipient 3699 concerning the busytime reply 3700 notice. 3702 CREATED S 3704 DURATION X 3706 DTEND S, Value is the ISO 8601 3707 complete representation, basic 3708 format of a UTC based date and 3709 time. Represents the end of 3710 the busy time period defined 3711 by the BUSYTIME properties in 3712 the Freebusy component. 3714 DTSTART S, Value is the ISO 8601 3715 complete representation, basic 3716 format of a UTC based date and 3717 time. Represents the start of 3718 the busy time period defined 3719 by the BUSYTIME properties in 3720 the Freebusy component. 3722 FREEBUSY A, Values in the property must 3723 all be of the same property 3724 parameter type. Multiple 3725 instances of the property are 3726 permitted. Multiple instances 3727 of the property must be sorted 3728 in ascending order. Values 3729 between property instances may 3730 overlap. 3732 LAST-MODIFIED S 3734 RELATED-TO S, Refers to a related 3735 Freebusy component. 3737 REQUEST- A, One of the values from the 3738 STATUS table below. Multiple 3739 instances of the property may 3740 be specified. 3742 RESPONSE- X, Will always be zero. 3744 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3745 May 1, 1997 3747 SEQUENCE 3749 SEQUENCE X, Will always be zero 3751 UID A, Must be the UID of the 3752 BUSY-REQUEST associated with 3753 the reply. 3755 URL S, Specifies the URL for HTTP 3756 access to a "VCS" file 3757 containing iCalendar Object 3758 with busy time information. 3760 Non-standard Properties 3762 X-token S, Recipient may choose to 3763 ignore those non-standard 3764 properties, specified as 3765 optional. 3767 The REQUEST-STATUS property may include the following values: 3769 Short Return Longer Return Status Offending Data 3770 Status Description 3772 0 Success. None. 3774 10 Success, but fallback Property name and value 3775 taken on one or more may be specified. 3776 property values. 3778 11 Success, invalid Property name may be 3779 property ignored. specified. 3781 12 Success, invalid Property parameter name 3782 property parameter and value may be 3783 ignored. specified. 3785 13 Success, unknown non- Non-standard property 3786 standard property name may be specified. 3787 ignored. 3789 14 Success, unknown non- Property and non- 3790 standard property value standard value may be 3791 ignored. specified. 3793 15 Success, invalid Calendar component 3794 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3795 May 1, 1997 3797 calendar component sentinel (e.g., 3798 ignored. "BEGIN:ALARM") may be 3799 specified. 3801 16 Success, request Original and forwarded 3802 forwarded to calendar RFC822 addresses may be 3803 user. specified. 3805 18 Success, truncated end 3806 date/time to date be specified. DTEND property value may 3807 boundary. 3809 100 Invalid property name. Property name may be 3810 specified. 3812 101 Invalid property value. Property name and value 3813 may be specified. 3815 102 Invalid property Property parameter name 3816 parameter. and value may be 3817 specified. 3819 103 Invalid property Property parameter name 3820 parameter value. and value may be 3821 specified. 3823 104 Invalid calendar Calendar component 3824 component sequence. sentinel may be 3825 specified (e.g., 3826 BEGIN:TIMEZONE). 3828 201 Invalid date or time. Date/time value(s) may 3829 be specified. 3831 203 Invalid request. Profile property value 3832 may be specified. 3834 204 Invalid calendar user. Attendee property value 3835 may be specified. 3837 302 Request not supported. PROFILE property value 3838 may be specified. 3840 401 Service unavailable. ATTENDEE property value 3841 may be specified. 3843 402 Invalid calendar ATTENDEE property value 3844 service. may be specified. 3846 403 Invalid calendar user. ATTENDEE property value 3847 may be specified. 3849 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3850 May 1, 1997 3852 404 No scheduling support ATTENDEE property value 3853 for user. may be specified. 3855 405 No authority. PROFILE and ATTENDEE 3856 property values may be 3857 specified. 3859 7. MIME Message Format Binding 3861 The iMIP is applicable to many transports; including vendor-specific 3862 electronic messaging formats, standards based electronic messaging 3863 formats such as the IETF SMTP/MIME, file system, common memory 3864 exchange such as a clipboard, drag/drop protocols, Infra-red Data 3865 Association (IrDA) object exchange, wireless pagers, etc. 3867 This section defines the message binding to the MIME electronic mail 3868 transport. 3870 7.1 MIME Media Type 3872 A MIME entity containing content information formatted according to 3873 this design document will be referenced as a "text/calendar" content 3874 type. It is assumed that this content type will be transported 3875 through a MIME electronic mail transport. 3877 7.2 Security 3879 When transported over SMIME, these messages should utilize the SMIME 3880 signature to prevent spoofing. 3882 7.3 RFC 822 Addresses 3884 The calendar address specified within the ATTENDEE property in a 3885 iCalendar object MUST be a fully qualified, RFC 822 address for the 3886 corresponding OWNER, ORGANIZER or ATTENDEE of the event or to-do. The 3887 address MUST be the RFC 822 address for the calendaring and 3888 scheduling mail box for the attendee. This may or may not be the same 3889 mail box that the individual uses for interpersonal messaging (i.e., 3890 email). The proper RFC 822 address will need to be identified and put 3891 into the ATTENDEE property by the calendaring and scheduling service. 3892 This information can not be assumed to be set by the electronic 3893 messaging MTA. 3895 A UA using MIME messages conforming to this design document may have 3896 different RFC 822 addresses for their electronic mail post office and 3897 the mail box used for calendaring and scheduling. In such cases, the 3898 addresses in the MIME header fields (e.g., To, From, Cc, Bc, Reply- 3899 to, etc.) may be different than the RFC 822 addresses specified in 3900 the ATTENDEE properties within the iCalendar object. 3902 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3903 May 1, 1997 3905 7.4 Content Type 3907 A MIME body part containing content information that conforms with 3908 this design document MUST have a Content-Type value of 3909 "text/calendar". The content type header field MUST also include the 3910 type parameter "profile". The parameter value MUST be one of the 3911 message types defined by this profile. The value MUST also be the 3912 same as the value of the PROFILE calendar property within the 3913 iCalendar object. This means that if a MIME message contains multiple 3914 iCalendar objects, then they must be further encapsulated with a 3915 "multipart/mixed" MIME entity. This will allow each of the iCalendar 3916 objects to be encapsulated within their own "text/calendar" MIME 3917 entity. 3919 If the iMIP based message is not an immediate child of the root MIME 3920 message entity, then it should be assumed to be a part of a forwarded 3921 message. It may be ignored. 3923 The Content-Type CHARSET parameter MUST also appear in any MIME 3924 entity encapsulating a iCalendar object conforming to this design 3925 document. The CHARSET parameter value MUST be "UTF-8" in order to 3926 override the default of "US-ASCII". 3928 The following is an example of this header field with a value that 3929 indicates an event request message. 3931 CONTENT-TYPE:text/calendar; profile=event-request; 3932 charset=UTF-8 3934 The "text/calendar" may be included as a MIME entity within either a 3935 "multipart/mixed" or "multipart/alternative" multi-part MIME message. 3936 This will allow the scheduling message type to be included in a MIME 3937 message with other content information (i.e., multipart/mixed) or 3938 included in a MIME message with a clear-text, human-readable form of 3939 the scheduling message (i.e., multipart/alternative). 3941 In order to permit the information in the scheduling message to be 3942 understood by MIME user agents (UA) that do not support the 3943 text/calendar content type, scheduling messages should be sent with 3944 an alternative, human-readable form of the information. 3946 [Editor's Note: An example is needed here.] 3948 7.5 Content-Transfer-Encoding 3950 The new Content-Transfer-Encoding header field was added in 3951 [RFC2045]. This header field specifies the encoding used to transform 3952 the content information into the MIME canonical content format. 3954 All MIME entities formatted according to this design document must be 3955 "8bit". This is to allow transfer of UTF-8 character set encoded 3956 iCalendar objects. The [RFC2045] default is "7bit". Hence, each MIME 3957 entity encapsulating a iCalendar object must include this header 3958 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 3959 May 1, 1997 3961 field. The following is an example of how this header field must 3962 appear. 3964 CONTENT-TRANSFER-ENCODING:8bit 3966 7.6 Content-Description 3968 The Content-Description header field is used to provide a human- 3969 readable explanation to the MIME entity. This is a useful field to 3970 record the fact that the content information is a iCalendar object. 3972 A MIME entities formatted according to this design document that 3973 includes this header field SHOULD have it's value prefixed with the 3974 text "X-iCAL:". 3976 7.7 To 3978 Any of the attendees addressed by the iCalendar object, that are also 3979 addressable with Internet SMTP addresses, should have their RFC 822 3980 addresses included in the TO header field. An attendee that is 3981 included in the iCalendar object but not in the TO header field is 3982 still a valid attendee to the event or to-do. 3984 7.8 From 3986 The originator of the iCalendar object should have their address in 3987 the value of the To header field. This may not be possible for 3988 iCalendar objects reflected from a mailing list. 3990 7.9 Cc and Bc 3992 Event or to-do attendees may be specified in the CC header field. 3993 This does not imply any special or limited role for the attendee. 3995 7.10 Reply-To 3997 The RFC 822 address of the originator of the iMIP MIME message should 3998 be specified as the value of the REPLY-TO header field. This will 3999 allow an electronic mail reply to the originator from the recipients 4000 of the iCalendar object. 4002 7.11 Subject 4004 The SUBJECT header field SHOULD be prefixed with the text "X-iCAL:" 4005 in order to allow the message to be detected as a iMIP by legacy 4006 systems. A MIME UA written to conform to this design document will 4007 use the Content-Type value and Profile parameter value as a primary 4008 means of detection. 4010 8. Alternate Plain-text Messages 4012 Some intended attendees for events or to-dos may be using a 4013 traditional, plain-text email user agent. They may not being using a 4014 calendaring and scheduling application that supports the iCalendar 4015 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4016 May 1, 1997 4018 Object. In such cases, a plain-text rendering of the iCalendar Object 4019 message would allow minimal support for some of the scheduling 4020 features defined by this document. The following formats are intended 4021 to be used to for this purpose. These alternative messages may be 4022 sent in a "multipart/alternative" MIME media type. 4024 8.1 EVENT-REQUEST, RSVP=YES 4026 The following is an alternative, plain-text message for an EVENT- 4027 REQUEST message, where a reply is requested. The SUBJECT property 4028 value SHOULD be the same as the event summary or the first 255 4029 character of the event description. 4031 is inviting you to a meeting as 4032 described below the line. Please put an "XXX" on the appropriate line 4033 below (and fill in any other necessary information) and then reply 4034 with this message to . 4036 _____ ACCEPT: I will attend this meeting. 4037 _____ DECLINE: I will not attend this meeting. 4038 _____ TENTATIVE: I do not now know whether I will attend this 4039 meeting. 4040 _____ DELEGATE: I will not attend this meeting -- I am inviting 4041 the following delegate and sending this message to 4042 him/her: _______________________ 4043 _____ PROPOSE ANOTHER TIME: I would like to attend this meeting 4044 but propose moving it to the following date and time: 4045 Date: ___________ 4046 Time: ___________ 4048 Attached Files: 4050 DO NOT MODIFY ANYTHING BELOW THIS LINE 4051 _____________________________________________________________________ 4053 Event ID: 4055 Meeting Summary: 4056 Start Date/Time: 4057 End Date/Time: 4058 Recurring Date(s): <"None" or substitute recurring dates/times> 4059 Location: 4061 Description: 4063 Invitees: 4065 8.2 EVENT-REQUEST, RSVP=NO 4067 The following is an alternative, plain-text message for an EVENT- 4068 REQUEST message, where a reply is NOT requested. The SUBJECT property 4069 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4070 May 1, 1997 4072 value SHOULD be the same as the event summary or the first 255 4073 character of the event description. 4075 is inviting you to a meeting as 4076 described below the line. There is no need to reply to this message, 4077 but please come to the meeting if you can. 4079 Attached Files: 4081 DO NOT MODIFY ANYTHING BELOW THIS LINE 4082 _____________________________________________________________________ 4084 Event ID: 4086 Meeting Summary: 4087 Start Date/Time: 4088 End Date/Time: 4089 Recurring Date(s): <"None" or substitute recurring dates/times> 4090 Location: 4092 Description: 4094 Invitees: 4096 8.3 EVENT-REQUEST, EXPECT=REQUIRED 4098 The following is an alternative, plain-text message for an EVENT- 4099 REQUEST message, where the attendee's attendance is required. This 4100 alternative message can also be used when the attendee's reply is 4101 requested (i.e., RSVP=YES). The SUBJECT property value SHOULD be the 4102 same as the event summary or the first 255 character of the event 4103 description. 4105 is inviting you to a meeting as 4106 described below the line. Your attendance is required in order for 4107 this meeting to take place. Please put an "XXX" on the appropriate 4108 line below (and fill in any other necessary information) and then 4109 reply with this message to . 4112 _____ ACCEPT: I will attend this meeting. 4113 _____ DECLINE: I will not attend this meeting. 4114 _____ TENTATIVE: I do not now know whether I will attend this 4115 meeting. 4116 _____ DELEGATE: I will not attend this meeting -- I am inviting 4117 the following delegate and sending this message to 4118 him/her: _______________________ 4119 _____ PROPOSE ANOTHER TIME: I would like to attend this meeting 4120 but propose moving it to the following date and time: 4121 Date: ___________ 4122 Time: ___________ 4123 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4124 May 1, 1997 4126 Attached Files: 4128 DO NOT MODIFY ANYTHING BELOW THIS LINE 4129 _____________________________________________________________________ 4131 Event ID: 4133 Meeting Summary: 4134 Start Date/Time: 4135 End Date/Time: 4136 Recurring Date(s): <"None" or substitute recurring dates/times> 4137 Location: 4139 Description: 4141 Invitees: 4143 8.4 EVENT-CANCEL 4145 The following is an alternative, plain-text message for an EVENT- 4146 CANCEL message. The SUBJECT property value SHOULD be the same as the 4147 event summary or the first 255 character of the event description. 4149 is canceling the meeting described 4150 below the line. Please remove it from your personal calendar. There 4151 is no need to reply to this message. 4153 Attached Files: 4155 DO NOT MODIFY ANYTHING BELOW THIS LINE 4156 _____________________________________________________________________ 4158 Event ID: 4160 Meeting Summary: 4161 Start Date/Time: 4162 End Date/Time: 4163 Location: 4165 Description: 4167 Invitees: 4169 8.5 EVENT-REPLACE, RSVP=YES 4171 The following is an alternative, plain-text message for an EVENT- 4172 REPLACE message, where a reply is requested. The SUBJECT property 4173 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4174 May 1, 1997 4176 value SHOULD be the same as the event summary or the first 255 4177 character of the event description. 4179 has changed the characteristics of 4180 this meeting. The meeting details are described below this line. 4181 Please put an "XXX" on the appropriate line below (and fill in any 4182 other necessary information) and then reply with this message to 4183 . 4185 _____ ACCEPT: I will attend this meeting. 4186 _____ DECLINE: I will not attend this meeting. 4187 _____ TENTATIVE: I do not now know whether I will attend this 4188 meeting. 4189 _____ DELEGATE: I will not attend this meeting -- I am inviting 4190 the following delegate and sending this message to 4191 him/her: _______________________ 4192 _____ PROPOSE ANOTHER TIME: I would like to attend this meeting 4193 but propose moving it to the following date and time: 4194 Date: ___________ 4195 Time: ___________ 4197 Attached Files: 4199 DO NOT MODIFY ANYTHING BELOW THIS LINE 4200 _____________________________________________________________________ 4202 Event ID: 4204 Meeting Summary: 4205 Original Start Date/Time: 4206 Original End Date/Time: 4207 Original Recurring Date(s): <"None" or substitute recurring 4208 dates/times> 4209 NEW Start Date/Time: 4210 NEW End Date/Time: 4211 NEW Recurring Date(s): <"None" or substitute recurring dates/times> 4212 NEW Location: 4214 NEW Description: 4216 Invitees: 4218 8.6 EVENT-DECLINECOUNTER 4220 The following is an alternative, plain-text message for an EVENT- 4221 DECLINECOUNTER. The SUBJECT property value SHOULD be the same as the 4222 event summary or the first 255 character of the event description. 4224 has declined your proposed change 4225 to the date and/or time for this meeting. Your proposed changes are 4226 detailed below the line. 4228 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4229 May 1, 1997 4231 DO NOT MODIFY ANYTHING BELOW THIS LINE 4232 _____________________________________________________________________ 4234 Event ID: 4236 Meeting Summary: 4237 Start Date and Time: 4238 End Date and Time: 4239 Location: 4241 Description: 4243 Invitees: 4245 8.7 EVENT-DELEGATE, RSVP=YES 4247 The following is an alternative, plain-text message for an EVENT- 4248 DELEGATE message, where a reply is requested. The SUBJECT property 4249 value SHOULD be the same as the event summary or the first 255 4250 character of the event description. 4252 has requested that you be their 4253 delegate at a meeting as described below the line. Please put an 4254 "XXX" on the appropriate line below (and fill in any other necessary 4255 information) and then reply with this message to and . 4259 _____ ACCEPT: I will attend this meeting. 4260 _____ DECLINE: I will not attend this meeting. 4261 _____ TENTATIVE: I do not now know whether I will attend this 4262 meeting. 4263 _____ DELEGATE: I will not attend this meeting -- I am inviting 4264 the following delegate and sending this message to 4265 him/her: _______________________ 4266 _____ PROPOSE ANOTHER TIME: I would like to attend this meeting 4267 but propose moving it to the following date and time: 4268 Date: ___________ 4269 Time: ___________ 4271 Attached Files: 4273 DO NOT MODIFY ANYTHING BELOW THIS LINE 4274 _____________________________________________________________________ 4276 Event ID: 4278 Meeting Summary: 4279 Start Date/Time: 4280 End Date/Time: 4281 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4282 May 1, 1997 4284 Location: 4286 Description: 4288 Invitees: 4290 8.8 TODO-REQUEST, RSVP=YES 4292 The following is an alternative, plain-text message for an TODO- 4293 REQUEST message, where a reply is requested. The SUBJECT property 4294 value SHOULD be the same as the event summary or the first 255 4295 character of the event description. 4297 is requesting you to do the task(s) 4298 as described below the line. Please put an "XXX" on the appropriate 4299 line below (and fill in any other necessary information) and then 4300 reply with this message to . 4303 _____ ACCEPT: I will do this task. 4304 _____ DECLINE: I will not do this task. 4305 _____ DELEGATE: I will not do this task -- I am delegating 4306 the task and sending this message to 4307 him/her: _______________________ 4309 Attached Files: 4311 DO NOT MODIFY ANYTHING BELOW THIS LINE 4312 _____________________________________________________________________ 4314 Event ID: 4316 To-do Summary: 4317 Start Date/Time: 4318 Due Date/Time: 4319 Recurring Due Date(s): <"None" or substitute recurring dates/times> 4320 Priority: 4322 Description: 4324 Invitees: 4326 8.9 TODO-REQUEST, RSVP=NO 4328 The following is an alternative, plain-text message for an TODO- 4329 REQUEST message, where a reply is NOT requested. The SUBJECT property 4330 value SHOULD be the same as the event summary or the first 255 4331 character of the event description. 4333 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4334 May 1, 1997 4336 is requesting you to do the task(s) 4337 as described below the line. 4339 Attached Files: 4341 DO NOT MODIFY ANYTHING BELOW THIS LINE 4342 _____________________________________________________________________ 4344 Event ID: 4346 To-do Summary: 4347 Start Date/Time: 4348 Due Date/Time: 4349 Recurring Due Date(s): <"None" or substitute recurring dates/times> 4350 Priority: 4352 Description: 4354 Invitees: 4356 8.10 TODO-CANCEL 4358 The following is an alternative, plain-text message for an TODO- 4359 CANCEL message. The SUBJECT property value SHOULD be the same as the 4360 todo summary or the first 255 character of the to-do description. 4362 is canceling the to-do described 4363 below the line. Please remove it from your personal calendar. There 4364 is no need to reply to this message. 4366 Attached Files: 4368 DO NOT MODIFY ANYTHING BELOW THIS LINE 4369 _____________________________________________________________________ 4371 To-do ID: 4373 To-do Summary: 4374 Start Date/Time: 4375 End Date/Time: 4376 Location: 4378 Description: 4380 Invitees: 4381 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4382 May 1, 1997 4384 8.11 JOURNAL-REQUEST, RSVP=YES 4386 The following is an alternative, plain-text message for an JOURNAL- 4387 REQUEST message, where a reply is requested. The SUBJECT property 4388 value SHOULD be the first 255 character of the event description. 4390 is requesting you add the journal 4391 entry as described below the line. Please put an "XXX" on the 4392 appropriate line below (and fill in any other necessary information) 4393 and then reply with this message to . 4396 _____ ACCEPT: I will do this journal entry. 4397 _____ DECLINE: I will not do this journal entry. 4398 _____ DELEGATE: I will not do this journal entry -- I am 4399 delegating the journal entry and sending this message 4400 to him/her: _______________________ 4402 Attached Files: 4404 DO NOT MODIFY ANYTHING BELOW THIS LINE 4405 _____________________________________________________________________ 4407 Journal ID: 4409 Journal Summary: 4410 Start Date/Time: 4412 Description: 4414 8.12 JOURNAL-REQUEST, RSVP=NO 4416 The following is an alternative, plain-text message for an JOURNAL- 4417 REQUEST message, where a reply is NOT requested. The SUBJECT property 4418 value SHOULD be the first 255 character of the event description. 4420 is requesting you add the journal 4421 entry as described below the line. 4423 Attached Files: 4425 DO NOT MODIFY ANYTHING BELOW THIS LINE 4426 _____________________________________________________________________ 4428 Journal ID: 4430 Journal Summary: 4431 Start Date/Time: 4432 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4433 May 1, 1997 4435 Description: 4437 9. IrDA Binding 4439 TBD. Initial text to be provided by Frank Dawson 4441 10. TCP LAN Protocol Binding 4443 TBD. Initial text to be provided by John Rose 4445 11. SPX LAN Protocol Binding 4447 TBD. Initial text to be provided by John Rose 4449 12. Desktop Interaction Requirements 4451 This section defines the minimal UI function client products MUST 4452 support in order to conform to this design document. 4454 12.1 Clipboard 4456 Applications conforming to this design document MUST provide the 4457 Edit-Copy or Edit-CopySpecial menu option and a smarticon to permit 4458 the end-user to copy a selected event or to-do to the operating 4459 system clipboard as a iCalendar object. 4461 The iCalendar object MUST be copied to the clipboard both as a 4462 iCalendar identifiable clipboard object and as a formatted-text 4463 clipboard object. This will allow copying of the iCalendar object to 4464 simple applications that just support formatted text clipboard 4465 objects. 4467 Applications conforming to this design document also MUST provide 4468 Edit-Paste or Edit-PasteSpecial menu option and a smarticon to permit 4469 the end-user to paste a clipboard based iCalendar object into the 4470 application. 4472 If the application does not find a iCalendar tagged object on the 4473 clipboard, it MUST try to find the iCalendar object in a simple 4474 formatted-text object on the clipboard. This will allow the 4475 application to interoperate with simple applications that support 4476 formatted-text clipboard representation of iCalendar objects but not 4477 yet support iCalendar tagged clipboard objects. 4479 12.2 Drag/Drop 4481 Applications conforming to this design document that runs in an 4482 environment with drag/drop MUST provide drag/source protocol support 4483 for the rendering an event or to-do as a iCalendar. 4485 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4486 May 1, 1997 4488 In addition, an application conforming to this design document that 4489 runs in an environment with drag/drop MUST provide drop/target 4490 protocol support for the import of a iCalendar object. 4492 If the operating system environment supports both a clipboard and 4493 file system based drag/drop protocol, then both of these modes MUST 4494 be supported for both drag/source and drag/target. 4496 12.3 File System 4498 Applications conforming to this design document MUST provide the 4499 File-SaveAs menu option and a smarticon to permit the end-user to 4500 export a selected event or to-do into the file system as a iCalendar 4501 object. The default file type MUST be "VCS". File systems that do not 4502 reply on file extensions may need alternative default extensions. 4504 Applications also MUST provide the File-Open menu option and a 4505 smarticon to permit the end-user to import a selected iCalendar 4506 object into the application. 4508 12.4 IrDa Communications 4510 Applications conforming to this design document SHOULD provide both 4511 the File-Send menu option and a iCalendar send smarticon to permit 4512 the end-user to "beam" a selected event or to-do over an operational 4513 IrDA communications port. 4515 The iCalendar "send" icon is available in a number of sizes and color 4516 densities from the http://www.imc.org/pdi web site. 4518 13. Conformance 4520 Applications conforming to this design document must meet the 4521 following minimum requirements: 4523 . Conform to the minimum requirements defined by the [ICAL] 4524 specification; 4526 . Also comply with the Mandatory requirements defined by this 4527 design document; 4529 . and optionally comply with any Optional requirements defined 4530 by this design document. 4532 14. References 4534 [ID-CSP] "MIME Calendaring and Scheduling Content Type Profile", 4535 Internet-Draft, November 26, 1996, ftp://ftp.ietf.org/internet- 4536 drafts/draft-ietf-calsch-csp-00.txt or http://www.imc.org/draft-ietf- 4537 calsch-csp. 4539 [ID-DT] "Date and Time on the Internet", Internet-Draft, December 4540 1996, http://www.imc.org/draft-newman-datetime. 4542 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4543 May 1, 1997 4545 [ICAL] "Internet Calendaring and Scheduling Core Object Specification 4546 - iCalendar", Internet-Draft, February 3, 1997, 4547 ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-00.txt. 4549 [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", 4550 Internet-Draft, July,1996, ftp://ftp.ietf.org/internet-drafts/draft- 4551 yergeau-utf8-01.txt. 4553 [ISO8601] "Data elements and interchange formats - information 4554 interchange - Representation of dates and times", ISO 8601, 1996-06- 4555 15, +1 (212) 642-4900 for ANSI Sales. 4557 [VCAL] "vCalendar - The Electronic Calendaring and Scheduling Format 4558 - Version 1.0", Versit Consortium, September 18, 1996, 4559 http://www.imc.org/pdi/vcal-10.doc. 4561 [VCARD] "vCard - The Electronic Business Card Exchange Format - 4562 Version 2.1", Versit Consortium, September 18, 1996, 4563 http://www.imc.org/pdi/vcard-21.doc. 4565 [RFC2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail 4566 Extensions - Part One - Format of Internet Message Bodies", RFC 2045, 4567 Innosoft, First Virtual, November 1996, http://www.imc.org/rfc2045. 4569 [RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail 4570 Extensions - Part Two - Media Types", RFC 2046, Innosoft, First 4571 Virtual, November 1996, http://www.imc.org/rfc2046. 4573 [UNICODE] The Unicode Consortium, "The Unicode Standard -Version 4574 2.0", Addison-Wesley Developers Press, July 1996. UTF-8 is described 4575 in section A-2. 4577 [US-ASCII] Coded Character Set--7-bit American Standard Code for 4578 Information Interchange, ANSI X3.4-1986. 4580 15. Acknowledgements 4582 The following individuals have made significant contributions to this 4583 document: 4585 John Banks-Binici, Polly Brown, Doug Conmy, Susan Esher, Arvind 4586 Goyal, Ryan Jansen, Bruce Kahn, Leo Parker, John Rose, Vinod 4587 Seraphin, Gail Strait. 4589 16. Author's Address 4591 The following address information is provided in a vCard v2.1, 4592 Electronic Business Card, format. 4594 BEGIN:VCARD 4595 ORG:Lotus Development Corporation 4596 FN:Frank Dawson 4597 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4598 May 1, 1997 4600 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive; 4601 Raleigh;NC;27613-3502;USA 4602 TEL;WORK;PREF;MSG:+1-919-676-9515 4603 TEL;WORK;MSG:+1-617-693-8728 4604 TEL;WORK;FAX:+1-919-676-9564 4605 EMAIL;INTERNET;PREF:Frank_Dawson@lotus.com 4606 EMAIL;INTERNET:fdawson@earthlink.net 4607 URL;HOME:http://home.earthlink.net/~fdawson 4608 END:VCARD 4610 17. Issues 4612 The following discussion relates to open design issues remained open 4613 when this version of the design document was completed. 4615 1. Need to resolve how to specify correct ATTENDEE values within a 4616 given product. A message may be transferred through a transport 4617 gateway. The address formats and content may be changed prior to 4618 recipient. In such cases, how is the recipient going to be able to 4619 reply to the originator? How is the originator going to be able to 4620 insert the ATTENDEE values into the message such that they are 4621 useful to the recipient? 4623 2. Request to UI for a human readable, "pretty" message counterpart 4624 to each of the messages. This needs to include a section with a 4625 text "response form" (e.g., check this box to provide a confirm 4626 reply). 4628 3. Binding to MIME multipart/alternative, multipart/related, and what 4629 to do for single body part. 4631 4. Do we allow a recipient to offer a counter proposal (i.e., EVENT- 4632 COUNTER) to an EVENT-REQUEST that describes a recurring event? 4634 5. Need a LAN binding for both TCP, AppleTalk, and SPX protocols (to 4635 be provided by John Rose/cc:Mail and John Cabot/Iris). 4637 6. Do we need a ROOM value for ATTENDEE;TYPE parameter. 4639 7. Should we be using a common vCard/iCalendar parser code base. 4641 18. Resolutions 4643 1. Implementation MUST be able to receive any message defined by this 4644 design document. Implementations MAY provide behaviors for a 4645 subset of the range of capabilities defined by this document 4646 (e.g., Might not put alarms in EVENT-REQUEST or Might ignore alarm 4647 properties in received EVENT-REQUEST messages). Implementations 4648 MUST not reject a message because of minimal support for the event 4649 or to-do description. 4651 2. ATTENDEE property values MUST be a fully qualified, RFC 822 4652 address. 4654 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4655 May 1, 1997 4657 3. Group scheduled to-dos MUST be supported. Both the TODO-REQUEST 4658 and TODO-REPLY message types MUST be supported. 4660 4. Implementations that do not support SUMMARY property MUST append 4661 the value to the DESCRIPTION property value. 4663 5. Implementations MUST store values for optional properties that 4664 they don't support. However, they may not act on these values. 4665 Optional, non-standard properties may be ignored by 4666 implementations that do not support the function. 4668 6. Implementations SHOULD include a text prefix of "X-iCAL:" in the 4669 Subject and Content-Description MIME header fields in order to 4670 allow legacy SMTP recipient to better handle text/calendar MIME 4671 message types. 4673 7. There are minimum length requirements for some properties by 4674 recipients of messages. For instance, a minimum of 4094 bytes MUST 4675 be supported by recipient for text values for the DESCRIPTION and 4676 COMMENT properties. A minimum of 254 bytes MUST be supported by 4677 recipients for text values for the SUMMARY property. Additional 4678 requirements for other properties may be identified later. 4679 Recipients MAY truncate longer property values. 4681 8. The C&S message is formatted as two alternative representations, 4682 if the message transport supports multiple part body parts. The 4683 initial body part is a pretty text equivalent of the C&S 4684 information. The second body part in the message is the 4685 interoperable message format defined by this design document. 4687 9. Any attachments to the event or to-do request are passed as 4688 secondary attachments. Their content identifiers are specified as 4689 the value for the associated ATTACH property. This assumes a 4690 multiple body part capability in the message transport. If this is 4691 not the case, then the attachments are send as independent 4692 messages. They message identifiers are specified as the value for 4693 the associated ATTACH property. 4695 10. For Internet mapping of messages, the ATTENDEE value needs to be 4696 the Internet RFC822 address for the mail box that receives C&S 4697 messages. For most people, this is the same as email address. This 4698 value DOES NOT include any comment texts, as specified in RFC 822. 4700 11. Person schema needs to provide flexibility for specifying a 4701 different email address for C&S. It should also specify a URL for 4702 busy time lookup. 4704 12. Allow event description (i.e., DTSTART, DTEND) to span day- 4705 boundary. The fallback for recipients that do not support this is 4706 to truncate the event description to the day-boundary (i.e., 4707 "T240000" is the DTEND time component of the date/time value). The 4708 remainder of the event duration is lost. 4710 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 4711 May 1, 1997 4713 13. The EVENT-REQUEST may include additional BEGIN/END:ALTERNATE 4714 calendar components that are the 1st, 2nd, 3rd, etc alternative 4715 times. The alternative ALTERNATE descriptions MUST reference the 4716 primary VEVENT with the REPLY-TO property containing the UID of 4717 the primary VEVENT. ATTENDESS reply with a REPLY message to only 4718 one event description. 4720 14. Local time will be interpreted by a recipient as being relative to 4721 their timezone. Date and time values in the DTSTART, DTEND, DUE, 4722 COMPLETED properties SHOULD be represented as a UTC date/time 4723 value unless they intent is that they be "floating" values. 4725 15. All iCalendar objects MUST use UTF-8 as the default character set.