idnits 2.17.1 draft-ietf-calsch-itip-part2-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-25) 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 48 longer pages, the longest (page 13) being 88 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 110 has weird spacing: '...reating an Ex...' == Line 2288 has weird spacing: '...reating an Ex...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? 'ICSM' on line 148 looks like a reference -- Missing reference section? 'ICAL' on line 2639 looks like a reference -- Missing reference section? 'ITIP-1' on line 2647 looks like a reference -- Missing reference section? 'ICMS' on line 2643 looks like a reference -- Missing reference section? 'SASL' on line 2618 looks like a reference -- Missing reference section? 'ID-DT' on line 2636 looks like a reference -- Missing reference section? 'ITIP-2' on line 2651 looks like a reference -- Missing reference section? 'ID-UTF8' on line 2655 looks like a reference -- Missing reference section? 'ISO8601' on line 2659 looks like a reference -- Missing reference section? 'RFC2045' on line 2663 looks like a reference -- Missing reference section? 'RFC2046' on line 2668 looks like a reference -- Missing reference section? 'UNICODE' on line 2672 looks like a reference -- Missing reference section? 'US-ASCII' on line 2678 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Dawson, Lotus 3 INTERNET-DRAFT R. Hopson, ON Technologies 4 S. Mansour, Netscape 5 Expires in six months from July 18, 1997 S. Silverberg, Microsoft 7 iCalendar Transport-Independent Interoperability Protocol 8 (iTIP) Part Two: Scheduling To-Dos 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months. Internet-Drafts may be updated, replaced, or made obsolete by 19 other documents at any time. It is not appropriate to use Internet- 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Distribution of this document is unlimited. 31 Abstract 33 This set of documents, collectively called the iCalendar Transport- 34 independent Interoperability Protocol, or iTIP, defines a transport- 35 independent message protocol to allow for searching for busy time and 36 the scheduling of events, journals, or journal entries on different 37 calendaring and scheduling systems. These documents are based on 38 earlier work documented in the iCalendar format. Because iCalendar 39 delt mainly with the format of calendaring information and said so 40 little about the method for conveying scheduling semantics, these 41 documents add scheduling semantics to the base calendaring 42 functionality defined in iCalendar. 44 The initial document specifies the messages for allowing searching 45 for free or busy time information and for scheduling events. The 46 second document defines the messages for scheduling to-dos, or action 47 items. The third document defines the messages for scheduling journal 48 entries. This document set is intended to convey calendaring and 49 scheduling semantics between different applications, independent of 50 transport. This document is also being offered as a specification for 51 demonstrating industry-wide, calendaring and scheduling 52 interoperability. The protocol defined by this document is applicable 53 for conveying calendaring and scheduling information across any 54 reliable transport. This format is useful for both client-to-server 55 communication, server-to-server communication, and client-to-client, 56 peer communication (e.g., PDA synchronization with a PIM). 58 Dawson/Hopson/Mansour/Silverberg 1 Expires January 1998 59 The breadth of this document is limited to exchanging only the to-do 60 type of calendar information. It does not address issues related to 61 events or journal entries. Instead, the document outlines a model for 62 calendar exchange that defines both static and dynamic to-do objects. 63 Static to-do objects are used to transmit to-dos from one entity to 64 another without the expectation of continuity or referential 65 integrity with the original item. Dynamic to-do objects are a 66 superset of static to-do objects and will gracefully degrade to their 67 static counterparts for clients that only support static to-do 68 objects. 70 Dawson/Hopson/Mansour/Silverberg 2 Expires January 1998 71 Table of Contents: 73 1. INTRODUCTION........................................................5 75 1.1 ITIP SCHEDULING TRANSACTIONS.....................................5 77 2. PROTOCOL MODELS.....................................................6 79 2.1 APPLICATION PROTOCOL.............................................6 80 2.1.1 Scheduling Transaction State..................................7 81 2.2 ADVANCED CALENDARING CONCEPTS....................................8 82 2.3 CALENDAR ROLES...................................................9 84 3. APPLICATION PROTOCOL ELEMENTS.......................................9 86 3.1 ITIP MESSAGE CONFORMANCE........................................10 87 3.1.1 Restrictions on DTSTART and DUE..............................11 88 3.2 SUMMARY OF APPLICATION PROTOCOL ELEMENTS........................11 89 3.2.1 TODO-PUBLISH.................................................11 90 3.2.2 TODO-REQUEST.................................................14 91 3.2.3 TODO-REPLY...................................................18 92 3.2.4 TODO-CANCEL..................................................20 93 3.2.5 Rescheduling or Changing a To-do.............................22 94 3.2.6 TODO-RESEND..................................................26 95 3.3 REQUEST STATUS CODES............................................29 97 4. EXAMPLES...........................................................31 99 4.1 PUBLISHED TO-DOS................................................31 100 4.1.1 A Minimal Published To-Do....................................32 101 4.1.2 Changing A Published To-Do...................................32 102 4.1.3 Canceling A Published To-Do..................................33 103 4.1.4 A Rich Published To-Do.......................................33 104 4.2 GROUP TO-DO EXAMPLES............................................35 105 4.2.1 A To-Do Request..............................................36 106 4.2.2 A To-Do Reply................................................36 107 4.2.3 Update A To-do...............................................37 108 4.3 RECURRING TO-DO AND TIME ZONE EXAMPLES..........................37 109 4.3.1 A Recurring To-do That Spans Timezones.......................37 110 4.3.2 Creating an Exception to a Recurring To-Do..................39 111 4.3.3 Modify Exception.............................................40 112 4.3.4 Cancel an Exception..........................................40 113 4.3.5 Cancel Recurring To-Do.......................................41 114 4.3.6 Decline A Previously Accepted Exception......................41 116 5. APPLICATION PROTOCOL FALLBACKS.....................................42 118 5.1 ICALENDAR PROFILE TYPES.........................................42 119 5.2 CALENDAR COMPONENTS.............................................42 120 5.3 CALENDAR PROPERTIES.............................................43 121 5.4 COMPONENT PROPERTIES............................................43 122 5.5 LATENCY ISSUES..................................................45 123 5.5.1 Cancelation of an Unknown To-do..............................45 124 5.6 SEQUENCE NUMBER.................................................45 126 6. SECURITY CONSIDERATIONS............................................45 128 Dawson/Hopson/Mansour/Silverberg 3 Expires January 1998 129 7. ACKNOWLEDGMENTS....................................................46 131 8. BIBLIOGRAPHY.......................................................46 133 9. AUTHORS ADDRESSES..................................................47 135 Dawson/Hopson/Mansour/Silverberg 4 Expires January 1998 136 1. Introduction 138 The purpose of this document set is to define the format of iCalendar 139 objects and how the iCalendar objects are conveyed between Calendar 140 User Agents (CUA) and Calendar Services (CS). This involves the 141 definition of a protocol that uses the iCalendar Object as the basis 142 for a collection of messages that are transmitted from one 143 calendaring system to another. The protocol is transport independent 144 but can be bound to either a real-time transport or a store-and- 145 forward transport such as e-mail. 147 This set of documents is based on the calendaring and scheduling 148 model specified in [ICSM]. 150 The first document in the set specifies the messages for allowing 151 searching for free or busy time information and for scheduling 152 events. This the second document, defines the messages for scheduling 153 to-dos, or action items. The third document defines the messages for 154 scheduling journal entries. Implemented as a whole, this document set 155 will allow different calendaring and scheduling domains to 156 interoperate; allowing for the seach for available free or busy time 157 information and scheduling events, to-dos, or daily journal entries. 159 1.1 iTIP Scheduling Transactions 161 The profiles described in section 3 (Application Protocol Elements) 162 may be considered usage profiles of the [ICAL] and is designed 163 specifically for the exchange of calendaring information between 164 scheduling applications. 166 To-do Publication 168 Publish a to-do; 170 Change a published to-do; 172 Cancel a published to-do. 174 Group To-dos 176 Request that a to-do be assigned to one or more recipients; 178 Reply to an existing to-do request to accept, decline, or 179 indicate completion of the to-do request; 181 Allow the organizer of a to-do to cancel the to-do; 183 Allow the organizer of a to-do to replace the original to-do 184 definition, as when a to-do description is clarified or the 185 attendee assignment information is updated; 187 Allow an attendee to request a resend of the current 188 description for an existing request. 190 Recurring To-dos and Timezones 192 Dawson/Hopson/Mansour/Silverberg 5 Expires January 1998 193 Support scheduling a to-do between individuals in different 194 time zones; 196 Support for time zones; 198 Support for DST rules; 200 Create a recurring to-do request with exception dates 202 2. Protocol Models 204 The protocol model for this part of iTIP is intended to be the same 205 as that described in iTIP Part 1. It is repeated here for clarity 206 when reading this document alone. 208 There are two distinct protocols that comprise iTIP: an Application 209 Protocol and a Transport Protocol. The Application Protocol defines 210 the content of the iCalendar objects sent between a sender and a 211 receiver in order to accomplish the various iTIP scheduling 212 transactions (section 1.1). The Transport protocol defines how the 213 iCalendar objects are sent between the sender and receiver. This 214 document focuses on the Application Protocol. Some considerations for 215 Transport Protocol documents are listed in Appendix A of [ITIP-1]. 217 +----------+ +----------+ 218 | | iTIP | | 219 | Sender |<-------------------->| Receiver | 220 | | | | 221 +----------+ +----------+ 223 There are several variations of this diagram in which the Sender and 224 Receiver take on various roles of CUA or CS. These variants are 225 detailed in the Model document [ICMS] 227 The architecture of iTIP is depicted in the diagram below. An 228 application written to this specification may utilize either the 229 binding for the store-and-forward transport, the real time transport, 230 or both. The iTIP could also be bound to other transports. If a 231 capability is not available on a particular transport binding, iTIP 232 provides a mechanism for indicating so. 234 +------------------------------------------+ 235 | iCalendar | 236 +------------------------------------------+ 237 | iTIP | 238 +------------------------------------------+ 239 |Real-time | Store and Fwd | Other | 240 |Transport | Transport | Transports... | 241 +------------------------------------------+ 243 2.1 Application Protocol 245 The model for the application protocol is originator-based (organizer 246 or owner roles for a request). That is, the originator of a request 247 sends it out to one or more invitees. The invitees reply back to the 249 Dawson/Hopson/Mansour/Silverberg 6 Expires January 1998 250 originator. The originator maintains the status of the event. Only 251 the originator can modify or cancel the request. 253 The data sources for the protocol are the Calendar Users as defined 254 in [ICMS]. Examples of these users are the originator (i.e., 255 organizer or owner) and attendees of an iCalendar to-do. The data 256 objects are the iCalendar objects that are exchanged between Calendar 257 Users. 259 2.1.1 Scheduling Transaction State 261 The state of the to-do scheduling transaction is described by the 262 STATUS and ATTENDEE properties in the to-do calendar component. 264 If there are no attendees in the calendar component, then this 265 implies the publish - state STATUS. 267 The state of a to-do request changes from the time it is initially 268 assigned, to when the attendees reply to the request, to when each of 269 the attendees complete the to-do. When an originator sends out the 270 to-do request, it's state with respect to the attendees is NEEDS 271 ACTION. If the attendee accepts the assignment, then the status is 272 changed to ACCEPTED. If the attendee rejects the assignment, then the 273 status is changed to DECLINED. When the attendee completes the to-do, 274 then the status is changed to COMPLETED. These changes in the 275 attendee status for the to-do are effected by the attendee sending 276 the originator a TODO-REPLY message with their updated status. 278 The general status of the to-do is reflected by the STATUS property. 279 The to-do STATUS property is controlled by the originator. There is 280 no default status. Initially, the originator should either set the 281 status to TENTATIVE or CONFIRMED. The originator can also set the 282 status to CANCELLED by sending a TODO-CANCEL message to the 283 attendees. The status is set to COMPLETED when all the attendees for 284 the to-do request have indicated their completion of the assignment 285 by sending the originator a TODO-REPLY message with their status set 286 to COMPLETED. 288 The states of the protocol are contained in the iCalendar object. Due 289 to the individual nature of a scheduling transaction, the state may 290 be different for each Calendar User. The diagram below describes the 291 various state changes. 293 Dawson/Hopson/Mansour/Silverberg 7 Expires January 1998 294 +===========================+========================== 295 | Owner / Originator | Attendee / Recipient | 296 +===========================+=========================+ 297 | TODO-PUBLISH -----------------------------------> | 298 | State=CONFIRMED | 299 +=====================================================+ 300 | TODO-REQUEST -----------------------------------> | 301 | State=CONFIRMED | TENTATIVE | 302 | Attendee Status=NEEDS ACTION | 303 | | 304 | <------------------------------------- TODO-REPLY | 305 | State=As specified in the TODO-REQUEST message | 306 | Attendee Status=ACCEPTED | DECLINED | COMPLETED | 307 +=====================================================+ 308 | TODO-CANCEL -----------------------------------> | 309 | State=CANCELLED | 310 | Attendee Status=As specified in the TODO-REPLY | 311 +=====================================================+ 312 | TODO-REQUEST -----------------------------------> | 313 | (A rescheduled or redefined to-do request) | 314 | State=CONFIRMED | TENTATIVE | 315 | Attendee Status=As defined in previous TODO- | 316 | REPLY message for this to-do | 317 +=====================================================+ 318 | <-------------------------------------TODO-RESEND | 319 | State=As specified in the TODO-REQUEST message | 320 | Attendee Status=As specified in the TODO-REPLY | 321 +=====================================================+ 323 2.2 Advanced Calendaring Concepts 325 The calendaring and scheduling capability defined by this document is 326 based on the exchange of messages between the organizer of a to-do 327 and one or more Calendar User Agents (CUA). The message protocol 328 emulates a "request" and "reply" form of communications. However, 329 there is a class of actions that are non-interactive and are more 330 consistent with publishing. These include the publishing of static 331 to-dos. 333 The message format is designed to be used with either a MIME 334 electronic messaging transport, real time protocols, and other 335 Internet and non-Internet transports. 336 This message-based protocol is based on "request" messages sent from 337 an originator and conveyed to one or more recipients. A recipient of 338 a "request" message may "reply" to the request, in order to update 339 their status and may also return transaction/request status 340 information. The protocol also supports the ability for the 341 originator of a to-do to change or cancel the original request. The 342 elements of the protocol also include the notion of user roles. 344 Dawson/Hopson/Mansour/Silverberg 8 Expires January 1998 345 2.3 Calendar Roles 347 Roles are a behavior or set of activities performed by particular 348 groups of users or agents at a particular time given the state of the 349 application. This specification describes 3 roles that determine a 350 range of actions and responsibilities specific to each role. When 351 scheduling a to-do with one or more individuals, there are 3 roles: 352 OWNER, ORGANIZER and ATTENDEE. The OWNER is generally the originator 353 of the to-do request. The OWNER sends the to-do request and receives 354 responses from the ATTENDEES. The OWNER is the effective owner of the 355 to-do. There are scenarios where the OWNER has an agent or associate 356 who acts on the OWNER's behalf, as is the case when your an assistant 357 makes assignments for you. In this scenario the ORGANIZER and the 358 OWNER are different individuals yet the ORGANIZER is still 359 responsible for sending and receiving the requests and managing the 360 calendar entities for this to-do. 362 Role Description 364 Organi The organizer is the calendar user that sends 365 zer and manages the to-do --- meaning responses 366 are directed at the organizer. In most cases 367 the organizer is also the owner, but in cases 368 where the owner has the organizer act on it's 369 behalf, the organizer becomes a proxy for the 370 owner. The organizer in this case would place 371 the to-do on the calendar of the owner. 373 Owner The owner generally controls direct 374 manipulation of the to-do. The owner can make 375 unilateral changes to the to-do while the 376 attendees can reply back to the owner. The 377 owner is usually the organizer, but in some 378 cases an agent or associate will act on 379 behalf of the owner and organize the to-do 380 and assignment logistics. 382 Attend Attendees are those recipients who are 383 ees assigned the group to-do. When an attendee 384 responds to the request, the attendee's 385 status property is set to either accept, 386 decline, tentative, or completed 388 3. Application Protocol Elements 390 Messages are the on-the-wire MIME entities that contain calendaring 391 information. The particular type of [ICAL] message is referred to as 392 the profile type. Each profile type is identified by a profile 393 property specified as part of the Text/Calendar content type. The 395 Dawson/Hopson/Mansour/Silverberg 9 Expires January 1998 396 following describes the various [ICAL] profile types supported in 397 this specification. 399 Profile Type Description 401 TODO-PUBLISH Post notification of a to-do. Used 402 primarily as a method of advertising the 403 existence of a to-do. The ATTENDEES 404 property is not included and no 405 interaction is expected. 407 TODO-REQUEST Make a to-do assignment. This is an 408 explicit assignment of a to-do to one or 409 more attendees. To-do requests are also 410 used to update or change an existing to- 411 do description. Clients that cannot 412 handle TODO-REQUEST messages can degrade 413 the to-do to view it as a TODO-PUBLISH. 415 TODO-REPLY Reply to a to-do request. This includes 416 "ACCEPT", "TENTATIVE", "DECLINE" and 417 "COMPLETED". 419 TODO-CANCEL Cancel an existing to-do request. Uses 420 the UID to identify the to-do to be 421 canceled. 423 TODO-RESEND Resend an existing to-do request. Uses 424 the UID to identify the to-do to be 425 resend. 427 Each profile type has an associated collection of properties and 428 methods. Some properties are required and others are optional. This 429 specification is also designed with the notion that some calendaring 430 clients will be capable of reading and posting to-dos (where posting 431 means to local calendar). Therefore, profiles such as TODO-REQUEST 432 will contain an exact superset of the TODO-PUBLISH property set such 433 that a client that supported TODO-PUBLISH could still read a TODO- 434 REQUEST. 436 3.1 ITIP Message Conformance 438 An implementation conforming to iTIP must enforce the conventions 439 described in the sections below. These conventions have been made to 440 improve interoperability. As a side benefit, they tend to simplify 441 implementation. 443 Dawson/Hopson/Mansour/Silverberg 10 Expires January 1998 444 3.1.1 Restrictions on DTSTART and DUE 446 The DTSTART property must always be specified. This specifies the 447 date/time that the to-do is to first be displayed. The DUE property 448 may be specified. This specifies the date/time that the to-do is 449 assigned to be completed. If the DUE property is missing, then the 450 implicit due date/time for the to-do is to be set to the current 451 date, until the to-do is completed. A to-do request containing DUE 452 without a DTSTART is not allowed. The DTSTART and the DUE properties 453 may have the same value. If the due date/time is known, the DUE 454 property should be specified. The DURATION property cannot be 455 specified in conjunction with DTSTART. 457 3.2 Summary of Application Protocol Elements 459 This section outlines the complete property set for each profile 460 type, indicating the required (designated by the word REQUIRED), 461 optional (designed by the words NOT REQUIRED) and excluded 462 (designated by the word EXCLUDED) properties. 464 3.2.1 TODO-PUBLISH 466 The TODO-PUBLISH is somewhat unique in this document in that it has 467 no response scheduling message associated with it. Instead, it is 468 simply a to-do that can be added by a calendar user agent to a 469 calendar as a static to-do entry. There is no defined response to the 470 originator of a TODO-PUBLISH message. It's expected usage is for 471 publication of to-dos such as those that might be published on a 472 website or Internet calendar. The TODO-PUBLISH is simply a MIME 473 encapsulated file that can be referenced and opened by the 474 appropriate handler for a TEXT/CALENDAR MIME content type and EVENT- 475 PUBLISH profile type. 477 TODO-PUBLISH 479 Calendar Properties 481 COMMENT 482 Not Required 484 GEO 485 Not Required 487 PRODID 488 Required 490 VERSION 491 Required, Value must be "2.0". 493 PROFILE 494 Required, "TODO-PUBLISH" 496 PROFILE-VERSION 497 Required, Value must be "1.0". 499 Timezone Component Properties 501 COMMENT 502 Not Required 504 Dawson/Hopson/Mansour/Silverberg 11 Expires January 1998 505 CREATED 506 Not Required 508 DAYLIGHT 509 Not Required 511 DTSTART 512 Required 514 DTSTART 515 Not Required 517 RDATE 518 Not Required, Either RDATE or 519 RRULE may be specified, but not 520 both. 522 RRULE 523 Not Required, Either RDATE or 524 RRULE may be specified, but not 525 both. 527 TZNAME 528 Not Required 530 TZOFFSET 531 Required 533 TZTRANS 534 Not Required 536 UID 537 Required 539 Event Component Properties 541 To-do component is excluded from 542 this message type. 544 To-do Component Properties 546 ATTACH 547 Not Required, "VALUE=URL" only. 549 ATTENDEE 550 Not Required 552 CATEGORIES 553 Not Required 555 CLASS 556 Not Required 558 COMMENT 559 Not Required 561 CREATED 562 Not Required 564 COMPLETED 565 Not Required 567 DESCRIPTION 568 Required, Value may be NULL 569 text. 571 DUE 572 Not Required 574 DURATION 575 Excluded 577 DTEND 578 Excluded 580 Dawson/Hopson/Mansour/Silverberg 12 Expires January 1998 581 DTSTAMP 582 Required 584 DTSTART 585 Required 587 EXDATE 588 Not Required 590 EXRULE 591 Not Required 593 LAST-MODIFIED 594 Not Required 596 LOCATION 597 Not Required 599 PRIORITY 600 Not Required 602 RELATED-TO 603 Not Required 605 REQUEST-STATUS 606 Excluded 608 RDATE 609 Not Required. 611 RRULE 612 Not Required. 614 RESOURCES 615 Not Required 617 RESPONSE-SEQUENCE 618 Excluded 620 SEQUENCE 621 Required, if not zero. 623 STATUS 624 Not Required. 626 SUMMARY 627 Not Required. May be NULL text. 629 TRANSP 630 Excluded 632 URL 633 Not Required 635 UID 636 Required 638 Journal Component Properties 640 Journal component is excluded 641 from this message type. 643 Alarm Component Properties 645 ATTACH 646 Not Required 648 CATEGORIES 649 Required, If an alarm is 650 specified 652 COMMENT 653 Not Required 655 CREATED 656 Not Required 658 Dawson/Hopson/Mansour/Silverberg 13 Expires January 1998 659 DESCRIPTION 660 Not Required 662 DTSTART 663 Required, If an alarm is 664 specified 666 DURATION 667 Required, If an alarm is 668 specified 670 LAST-MODIFIED 671 Not Required 673 RELATED-TO 674 Not Required 676 REPEAT 677 Required, If an alarm is 678 specified 680 SUMMARY 681 Not Required 683 URL 684 Not Required 686 Freebusy Properties 688 Freebusy component is excluded 689 from this message type. 691 Non-standard Properties 693 X-token 694 Not Required, but recipient may 695 choose to ignore those non- 696 standard properties, specified 697 as Not Required. 699 3.2.2 TODO-REQUEST 701 The TODO-REQUEST is used to both describe a to-do and assign the to- 702 do to one or more attendees. When a TODO-REQUEST is received by a 703 user it should be responded to with a TODO-REPLY. 705 TODO-REQUEST 707 Calendar Properties 709 COMMENT 710 Not Required 712 GEO 713 Not Required 715 PRODID 716 Required 718 VERSION 719 Required, Value must be "2.0". 721 PROFILE 722 Required,"TODO-REQUEST" 724 Dawson/Hopson/Mansour/Silverberg 14 Expires January 1998 725 PROFILE-VERSION 726 Required, Value must be "1.0". 728 Timezone Component Properties 730 COMMENT 731 Not Required 733 CREATED 734 Not Required 736 DAYLIGHT 737 Not Required 739 DTSTART 740 Required 742 DTEND 743 Not Required 745 RDATE 746 Not Required, Either RDATE or 747 RRULE may be specified, but 748 not both. 750 RRULE 751 Not Required, Either RDATE or 752 RRULE may be specified, but 753 not both. 755 TZNAME 756 Not Required 758 TZOFFSET 759 Required 761 TZTRANS 762 Not Required 764 Event Component Properties 766 To-do component is excluded 767 from this message type. 769 To-do Component Properties 771 ATTACH 772 Not Required, "VALUE=URL" 773 only. 775 ATTENDEE 776 Required, Value is an RFC822 777 mailbox address for C&S 778 capability. STATUS parameter 779 is either absent or has value 780 "NEEDS ACTION". 782 CATEGORIES 783 Not Required 785 CLASS 786 Not Required 788 COMMENT 789 Not Required 791 CREATED 792 Not Required 794 COMPLETED 795 Not Required 797 Dawson/Hopson/Mansour/Silverberg 15 Expires January 1998 798 DESCRIPTION 799 Required, Value may be NULL 800 text. 802 DUE 803 Not Required 805 DURATION 806 Excluded 808 DTEND 809 Excluded 811 DTSTAMP 812 Required 814 DTSTART 815 Required 817 EXDATE 818 Not Required. 820 EXRULE 821 Not Required. 823 LAST-MODIFIED 824 Not Required 826 LOCATION 827 Not Required 829 PRIORITY 830 Not Required 832 RELATED-TO 833 Not Required 835 REQUEST-REPLY 836 Excluded 838 RDATE 839 Not Required. 841 RRULE 842 Not Required. 844 RESOURCES 845 Not Required 847 RESPONSE-SEQUENCE 848 Excluded 850 SEQUENCE 851 Required, If not zero. 853 STATUS 854 Not Required, Value only one 855 of TENTATIVE | ACCEPTED | 856 CANCELLED. This property is 857 used by the originator to 858 indicate the consensus for the 859 to-do, not a status on any of 860 the attendees. 862 SUMMARY 863 Not Required, May be NULL 864 text. 866 TRANSP 867 Excluded 869 URL 870 Not Required 872 Dawson/Hopson/Mansour/Silverberg 16 Expires January 1998 873 UID 874 Required, Must be maintained 875 by the recipients. 877 Journal Component Properties 879 Journal component is excluded 880 from this message type. 882 Alarm Component Properties 884 ATTACH 885 Not Required 887 CATEGORIES 888 Required, If an alarm is 889 specified 891 COMMENT 892 Not Required 894 CREATED 895 Not Required 897 DESCRIPTION 898 Not Required 900 DTSTART 901 Required, If an alarm is 902 specified 904 DURATION 905 Required, If an alarm is 906 specified 908 LAST-MODIFIED 909 Not Required 911 RELATED-TO 912 Not Required 914 REPEAT 915 Required, If an alarm is 916 specified 918 SUMMARY 919 Not Required 921 URL 922 Not Required 924 Freebusy Properties 926 Freebusy component is excluded 927 from this message type. 929 Non-standard Properties 931 X-token 932 Not Required, but recipient 933 may choose to ignore those 934 non-standard properties, 935 specified as Not Required. 937 Dawson/Hopson/Mansour/Silverberg 17 Expires January 1998 938 3.2.3 TODO-REPLY 940 The TODO-REPLY is used to by the attendees to reply to the originator 941 of the to-do request with their status. The attendees can indicate 942 their status is a TENTATIVE acceptance, that they have ACCEPTED the 943 assignment, that they DECLINED the assignment or that they have 944 COMPLETED the assignment. Once an attendee has replied to the 945 request, they can subsequently reply with a different value. 947 TODO-REPLY 949 Calendar Properties 951 COMMENT 952 Not Required 954 GEO 955 Not Required 957 PRODID 958 Required 960 VERSION 961 Required, Value must be "2.0". 963 PROFILE 964 Required,"TODO-REPLY" 966 PROFILE-VERSION 967 Required, Value must be "1.0". 969 Timezone Component Properties 971 Timezone component is excluded 972 from this message type. 974 Event Component Properties 976 Event component is excluded 977 from this message type. 979 To-do Component Properties 981 ATTACH 982 Excluded 984 ATTENDEE 985 Required, Value is an RFC822 986 mailbox address for C&S 987 capability. Must be the 988 address of the recipient 989 replying. 991 CATEGORIES 992 Excluded 994 CLASS 995 Excluded 997 COMMENT 998 Text value. Provides a comment 999 from the recipient to the 1000 originator about the reply. 1001 For example, "I am too busy to 1002 accept this assignment." 1004 Dawson/Hopson/Mansour/Silverberg 18 Expires January 1998 1005 CREATED 1006 Excluded 1008 COMPLETED 1009 Not Required 1011 DESCRIPTION 1012 Excluded 1014 DUE 1015 Excluded 1017 DURATION 1018 Excluded 1020 DTEND 1021 Excluded 1023 DTSTAMP 1024 Required 1026 DTSTART 1027 Excluded 1029 EXDATE 1030 Not Required. Specifies the 1031 dates that are exceptions to 1032 the status update. 1034 EXRULE 1035 Not Required. Specifies the 1036 rule that defines the 1037 exceptions to the status 1038 update. 1040 LAST-MODIFIED 1041 Excluded 1043 LOCATION 1044 Excluded 1046 PRIORITY 1047 Excluded 1049 RELATED-TO 1050 Excluded 1052 REQUEST-STATUS 1053 Not Required. Any of the 1054 values defined in the table 1055 below. 1057 RDATE 1058 Excluded 1060 RRULE 1061 Excluded 1063 RESOURCES 1064 Excluded 1066 RESPONSE-SEQUENCE 1067 Required, If not zero. 1069 SEQUENCE 1070 Required, If not zero 1072 STATUS 1073 Excluded. Status for attendee 1074 must be specified in STATUS 1075 parameter of ATTENDEE 1076 property. 1078 Dawson/Hopson/Mansour/Silverberg 19 Expires January 1998 1079 SUMMARY 1080 Excluded 1082 TRANSP 1083 Excluded 1085 URL 1086 Excluded 1088 UID 1089 Required, Must be the UID of 1090 the EVENT-REQUEST associate 1091 with the reply. 1093 Journal Component Properties 1095 Journal component is excluded 1096 from this message type. 1098 Alarm Component Properties 1100 Alarm component is excluded 1101 from this message type. 1103 Freebusy Properties 1105 Freebusy component is excluded 1106 from this message type. 1108 Non-Standard Properties 1110 X-token 1111 Not Required, but recipient 1112 may choose to ignore those 1113 non-standard properties, 1114 specified as Not Required. 1116 3.2.4 TODO-CANCEL 1118 The TODO-CANCEL is used to by the originator of the to-do request to 1119 convey a cancellation notice of the to-do to the attendees. The 1120 message is only sent by the to-do OWNER or ORGANIZER to the 1121 recipients of the original to-do request. 1123 TODO-CANCEL 1125 Calendar Properties 1127 COMMENT 1128 Not Required 1130 GEO 1131 Not Required 1133 PRODID 1134 Required 1136 VERSION 1137 Required, Value must be "2.0". 1139 PROFILE 1140 Required,"TODO-CANCEL" 1142 PROFILE-VERSION 1143 Required, Value must be "1.0". 1145 Dawson/Hopson/Mansour/Silverberg 20 Expires January 1998 1146 Timezone Component Properties 1148 Timezone component is excluded 1149 from this message type. 1151 Event Component Properties 1153 Event component is excluded 1154 from this message type. 1156 To-do Component Properties 1158 ATTACH 1159 Excluded 1161 ATTENDEE 1162 Excluded 1164 CATEGORIES 1165 Excluded 1167 CLASS 1168 Excluded 1170 CREATED 1171 Excluded 1173 COMMENT 1174 Not Required, Text value. 1175 Provides a comment from the 1176 originator to the attendees 1177 concerning the cancellation 1178 notice. 1180 COMPLETED 1181 Excluded 1183 DESCRIPTION 1184 Excluded 1186 DUE 1187 Excluded 1189 DURATION 1190 Excluded 1192 DTEND 1193 Excluded 1195 DTSTAMP 1196 Excluded 1198 DTSTART 1199 Excluded 1201 EXDATE 1202 Excluded 1204 EXRULE 1205 Excluded 1207 LAST-MODIFIED 1208 Excluded 1210 LOCATION 1211 Excluded 1213 PRIORITY 1214 Excluded 1216 RELATED-TO 1217 Excluded 1219 Dawson/Hopson/Mansour/Silverberg 21 Expires January 1998 1220 REQUEST-STATUS 1221 Excluded 1223 RDATE 1224 Excluded 1226 RRULE 1227 Excluded 1229 RESOURCES 1230 Excluded 1232 RESPONSE-SEQUENCE 1233 Excluded 1235 SEQUENCE 1236 Required, if not zero. Is not 1237 incremented by this action. 1239 STATUS 1240 Not Required, If present value 1241 must be "CANCELLED". 1243 SUMMARY 1244 Excluded 1246 TRANSP 1247 Excluded 1249 URL 1250 Not Required 1252 UID 1253 Required, Must be the UID of 1254 the original EVENT-REQUEST 1255 associated with the 1256 cancellation notice. 1258 Journal Component Properties 1260 Journal component is excluded 1261 from this message type. 1263 Alarm Properties 1265 Alarm component is excluded 1266 from this message type. 1268 Freebusy Protperties 1270 Freebusy component is excluded 1271 from this message type. 1273 Non-standard Properties 1275 X-token 1276 Not Required, But recipient 1277 may choose to ignore those 1278 non-standard properties, 1279 specified as optional. 1281 3.2.5 Rescheduling or Changing a To-do 1283 When an owner/organizer desires to reschedule or change some detail 1284 of one of their existing to-do requests, they effect this change by 1285 conveying a new to-do request with the same UID and an incremented 1287 Dawson/Hopson/Mansour/Silverberg 22 Expires January 1998 1288 sequence number. The receiving client must correlate the request to 1289 their existing to-dos and check the sequence number in order to 1290 realize that the request is actually a replacement for the existing 1291 to-do. Individual "A" sends a to-do request to "B" and "C". "B" 1292 accepts the to-do and "C" declines and includes text in the comments 1293 property proposing a more appropriate due date. "A" sends "B" and "C" 1294 another to-do request using the same UID and a sequence number one 1295 greater than the original request. "B" should infer that the to-do 1296 request message is actually a replacement for the existing to-do. 1298 Replacing a to-do request is predicated on using the same UID, 1299 incrementing the sequence number and replacing the changed calendar 1300 properties. 1302 TODO-REQUEST (replacing an existing to-do description) 1304 Calendar Properties 1306 COMMENT 1307 Not Required 1309 GEO 1310 Not Required 1312 PRODID 1313 Required 1315 VERSION 1316 Required, Value must be "2.0". 1318 PROFILE 1319 Required,"TODO-REQUEST" 1321 PROFILE-VERSION 1322 Required, Value must be "1.0". 1324 Timezone Component Properties 1326 COMMENT 1327 Not Required 1329 CREATED 1330 Not Required 1332 DAYLIGHT 1333 Not Required 1335 DTSTART 1336 Required 1338 DTEND 1339 Not Required 1341 RDATE 1342 Not Required, Either RDATE or 1343 RRULE may be specified, but 1344 not both. 1346 RRULE 1347 Not Required, Either RDATE or 1348 RRULE may be specified, but 1349 not both. 1351 TZNAME 1352 Not Required 1354 TZOFFSET 1355 Required 1357 Dawson/Hopson/Mansour/Silverberg 23 Expires January 1998 1358 TZTRANS 1359 Not Required 1361 Event Component Properties 1363 Event component is excluded 1364 from this message type. 1366 To-do Component Properties 1368 ATTACH 1369 Not Required, "VALUE=URL" 1370 only. 1372 ATTENDEE 1373 Required, Value is an RFC822 1374 mailbox address for C&S 1375 capability. STATUS parameter 1376 is either absent or has value 1377 "NEEDS ACTION". 1379 CATEGORIES 1380 Not Required 1382 CLASS 1383 Not Required 1385 COMMENT 1386 Not Required 1388 CREATED 1389 Not Required 1391 COMPLETED 1392 Excluded 1394 DESCRIPTION 1395 Required, Value may be NULL 1396 text. 1398 DUE 1399 Not Required, must be after or 1400 the same as the DTSTART 1401 date/time. 1403 DURATION 1404 Excluded 1406 DTEND 1407 Excluded 1409 DTSTAMP 1410 Required 1412 DTSTART 1413 Required 1415 EXDATE 1416 Not Required. 1418 EXRULE 1419 Not Required. 1421 LAST-MODIFIED 1422 Not Required 1424 LOCATION 1425 Not Required 1427 PRIORITY 1428 Not Required 1430 Dawson/Hopson/Mansour/Silverberg 24 Expires January 1998 1431 RELATED-TO 1432 Not Required 1434 REQUEST-STATUS 1435 Excluded 1437 RDATE 1438 Not Required 1440 RRULE 1441 Not Required 1443 RESOURCES 1444 Not Required 1446 RESPONSE-SEQUENCE 1447 Excluded 1449 SEQUENCE 1450 Must be greater than 0 and 1451 should be monotomically 1452 incremented for each request 1454 STATUS 1455 Not Required, Value only one 1456 of TENTATIVE | CONFIRMED | 1457 CANCELLED. This property is 1458 used by the originator to 1459 indicate the consensus for the 1460 to-do, not a status on any of 1461 the attendees. 1463 SUMMARY 1464 Not Required, May be NULL 1465 text. 1467 TRANSP 1468 Excluded 1470 URL 1471 Not Required 1473 UID 1474 Required, Must match the 1475 original meeting request which 1476 this request replaces 1478 Journal Component Properties 1480 Journal component is excluded 1481 from this message type. 1483 Alarm Component Properties 1485 ATTACH 1486 Not Required 1488 CATEGORIES 1489 Required, If an alarm is 1490 specified 1492 CREATED 1493 Not Required 1495 DESCRIPTION 1496 Not Required 1498 DTSTART 1499 Required, If an alarm is 1500 specified 1502 Dawson/Hopson/Mansour/Silverberg 25 Expires January 1998 1503 DURATION 1504 Required, If an alarm is 1505 specified 1507 LAST-MODIFIED 1508 Not Required 1510 RELATED-TO 1511 Not Required 1513 REPEAT 1514 Required, If an alarm is 1515 specified 1517 SUMMARY 1518 Not Required 1520 URL 1521 Not Required 1523 Freebusy Component Properties 1525 Freebusy component is excluded 1526 from this message type. 1528 Non-standard Properties 1530 X-token 1531 Not Required, but recipient 1532 may choose to ignore those 1533 non-standard properties, 1534 specified as Not Required. 1536 3.2.6 TODO-RESEND 1538 The TODO-RESEND is used by attendees to request the latest version of 1539 a TODO-REQUEST. By issuing an TODO-RESEND, with the appropriate UID 1540 and optionally a RECURRENCE-ID, the organizer's CUA should respond 1541 with the latest version of the to-do. This message type is intended 1542 to be machine processed. 1544 TODO-RESEND 1546 Calendar Properties 1548 COMMENT 1549 Not Required 1551 GEO 1552 Not Required 1554 PRODID 1555 Required 1557 VERSION 1558 Required, Value must be "2.0". 1560 PROFILE 1561 Required,"TODO-RESEND" 1563 PROFILE-VERSION 1564 Required, Value must be "1.0". 1566 Timezone Component Properties 1568 Dawson/Hopson/Mansour/Silverberg 26 Expires January 1998 1569 Timezone component is excluded 1570 from this message type. 1572 Event Component Properties 1574 Event component is excluded 1575 from this message type. 1577 To-do Component Properties 1579 ATTACH 1580 Excluded 1582 ATTENDEE 1583 Excluded 1585 CATEGORIES 1586 Excluded 1588 CLASS 1589 Excluded 1591 CREATED 1592 Excluded 1594 COMMENT 1595 Not Required, Text value. 1596 Provides a comment from the 1597 attendee to the organizer 1598 concerning the resend request. 1600 COMPLETED 1601 Excluded 1603 DESCRIPTION 1604 Excluded 1606 DUE 1607 Excluded 1609 DURATION 1610 Excluded 1612 DTEND 1613 Excluded 1615 DTSTAMP 1616 Required 1618 DTSTART 1619 Excluded 1621 EXDATE 1622 Excluded 1624 EXRULE 1625 Excluded 1627 LAST-MODIFIED 1628 Excluded 1630 LOCATION 1631 Excluded 1633 PRIORITY 1634 Excluded 1636 RELATED-TO 1637 Excluded 1639 REQUEST-STATUS 1640 Excluded 1642 Dawson/Hopson/Mansour/Silverberg 27 Expires January 1998 1643 RDATE 1644 Excluded 1646 RRULE 1647 Excluded 1649 RECURRENCE-ID 1650 Not Required. If the attendee 1651 wishes to receive an updated 1652 instance of a recurring to-do, 1653 then the RECURRENCE-ID can be 1654 included and only the specific 1655 instance will be returned. 1657 RESOURCES 1658 Excluded 1660 RESPONSE-SEQUENCE 1661 Excluded 1663 SEQUENCE 1664 Required, if not zero. Is not 1665 incremented by this action. 1667 STATUS 1668 Excluded 1670 SUMMARY 1671 Excluded 1673 TRANSP 1674 Excluded 1676 URL 1677 Excluded 1679 UID 1680 Required, Must be the UID of 1681 the original EVENT-REQUEST 1682 associated with the 1683 cancellation notice. 1685 Journal Component Properties 1687 Journal component is excluded 1688 from this message type. 1690 Alarm Properties 1692 Alarm component is excluded 1693 from this message type. 1695 Freebusy Protperties 1697 Freebusy component is excluded 1698 from this message type. 1700 Non-standard Properties 1702 X-token 1703 Not Required, But recipient 1704 may choose to ignore those 1705 non-standard properties, 1706 specified as optional. 1708 Dawson/Hopson/Mansour/Silverberg 28 Expires January 1998 1709 3.3 Request Status Codes 1711 The following is a list of possible return status codes values: 1713 Short Longer Return Status Offending Data 1714 Return Description 1715 Status 1716 Code 1718 200 1719 Success. None. 1721 201 1722 Success, but fallback Property name and 1723 taken on one or more value may be 1724 property values. specified. 1726 202 1727 Success, invalid Property name may be 1728 property ignored. specified. 1730 203 1731 Success, invalid Property parameter 1732 property parameter name and value may be 1733 ignored. specified. 1735 204 1736 Success, unknown non- Non-standard property 1737 standard property name may be 1738 ignored. specified. 1740 205 1741 Success, unknown non- Property and non- 1742 standard property value standard value may be 1743 ignored. specified. 1745 206 1746 Success, invalid Calendar component 1747 calendar component sentinel (e.g., 1748 ignored. "BEGIN:ALARM") may be 1749 specified. 1751 207 1752 Success, request Original and 1753 forwarded to calendar forwarded RFC822 1754 user. addresses may be 1755 specified. 1757 208 1758 Success, repeating event RRULE or RDATE 1759 ignored. Scheduled as a property name and 1760 single event. value may be 1761 specified. 1763 209 1764 Success, truncated end DTEND property value 1765 date/time to date may be specified. 1766 boundary. 1768 210 1769 Success, repeating to-do RRULE or RDATE 1770 ignored. Scheduled as a property name and 1772 Dawson/Hopson/Mansour/Silverberg 29 Expires January 1998 1773 single to-do. value may be 1774 specified. 1776 300 1777 Invalid property name. Property name may be 1778 specified. 1780 301 1781 Invalid property value. Property name and 1782 value may be 1783 specified. 1785 302 1786 Invalid property Property parameter 1787 parameter. name and value may be 1788 specified. 1790 303 1791 Invalid property Property parameter 1792 parameter value. name and value may be 1793 specified. 1795 304 1796 Invalid calendar Calendar component 1797 component sequence. sentinel may be 1798 specified (e.g., 1799 BEGIN:TIMEZONE). 1801 305 1802 Invalid date or time. Date/time value(s) 1803 may be specified. 1805 306 1806 Invalid rule. Rule value may be 1807 specified. 1809 307 1810 Invalid calendar user. Attendee property 1811 value may be 1812 specified. 1814 308 1815 No authority. PROFILE and ATTENDEE 1816 property values may 1817 be specified. 1819 309 1820 Unsupported version. VERSION property name 1821 and value may be 1822 specified. 1824 310 1825 Request entity too None. 1826 large. 1828 400 1829 Event conflict. DTSTART and DTEND 1830 Date/time is busy. property name and 1831 values may be 1832 specified. 1834 500 1835 Request not supported. Profile property 1836 value may be 1837 specified. 1839 Dawson/Hopson/Mansour/Silverberg 30 Expires January 1998 1840 501 1841 Service unavailable. ATTENDEE property 1842 value may be 1843 specified. 1845 502 1846 Invalid calendar ATTENDEE property 1847 service. value may be 1848 specified. 1850 503 1851 No scheduling support ATTENDEE property 1852 for user. value may be 1853 specified. 1855 4. Examples 1857 4.1 Published To-Dos 1859 In the calendaring and scheduling context, publication refers to the 1860 one way transfer of to-do information. Consumers of published to-dos 1861 simply incorporate the to-do into a calendar. No reply is expected. 1862 Individual "A" publishes a to-do. Individual "B" reads the to-do and 1863 incorporates it into their calendar. To-dos can be published in 1864 several ways including: embedding the to-do as an object in a web 1865 page, e-mailing the to-do to a distribution list, and posting the to- 1866 do to a newsgroup. 1868 The table below illustrates the sequence of to-dos between the 1869 publisher and the consumers of a published to-do. 1871 Action Organizer Attendee 1873 Publish a to-do "A" sends or posts a 1874 TODO-PUBLISH message 1876 "B" reads the to- 1877 do publication 1879 Publish an updated "A" sends or posts a 1880 to-do TODO-PUBLISH message 1882 "B" reads the 1883 updated to-do 1884 publication 1886 Cancel a published "A" sends or posts a 1887 to-do toDO-CANCEL message 1889 "B" reads the 1890 canceled to-do 1892 Dawson/Hopson/Mansour/Silverberg 31 Expires January 1998 1893 publication 1895 4.1.1 A Minimal Published To-Do 1897 The iCalendar Object below describes a single to-do is due on October 1898 1, 1997 at 20:00 UTC. This to-do contains the minimum set of 1899 properties for an iTIP to-do component. 1901 BEGIN:VCALENDAR 1902 PROFILE:TODO-PUBLISH 1903 PROFILE-VERSION:1.0 1904 PRODID:-//ACME/DesktopCalendar//EN 1905 VERSION:2.0 1906 BEGIN:VTODO 1907 DUE:19971001T200000Z 1908 SUMMARY:Book Report on Fiction Novel 1909 UID:0981234-1234234-2300 1910 DTSTAMP:19970717T200000Z 1911 END:VTODO 1912 END:VCALENDAR 1914 4.1.2 Changing A Published To-Do 1916 The iCalendar Object below describes an update to the to-do described 1917 in 4.1.1, the due date has been changed, a start time has been added, 1918 and the sequence number has been adjusted. 1920 BEGIN:VCALENDAR 1921 PROFILE:TODO-PUBLISH 1922 PROFILE-VERSION:1.0 1923 VERSION:2.0 1924 PRODID:-//ACME/DesktopCalendar//EN 1925 BEGIN:VTODO 1926 DTSTART:19970901T210000Z 1927 DUE:19971005T200000Z 1928 SEQUENCE:2 1929 UID:0981234-1234234-2300 1930 SUMMARY:Book Report on Fiction Novel 1931 DTSTAMP:19970717T200000Z 1932 STATUS:NEEDS-ACTION 1933 END:VTODO 1934 END:VCALENDAR 1936 To identify the to-do the client uses the UID. The SEQUENCE property 1937 indicates that this is the second change to the to-do. To-dos with 1938 sequence numbers 0 and 1 are superseded by this to-do. 1940 The SEQUENCE property provides a reliable way to distinguish 1941 different versions of the same to-do. Each time a to-do is published, 1942 its sequence number is incremented. If a client receives a to-do with 1943 a sequence number 5 and finds it has the same to-do with sequence 1944 number 2, the to-do should be updated. However, if the client 1946 Dawson/Hopson/Mansour/Silverberg 32 Expires January 1998 1947 received a to-do with sequence number 2 and finds it already has 1948 sequence number 5 of the same to-do, the to-do should not be updated. 1950 4.1.3 Canceling A Published To-Do 1952 The iCalendar Object below cancels the to-do described in 4.1.1. This 1953 cancels the to-do with SEQUENCE numbers 0, 1, and 2. 1955 BEGIN:VCALENDAR 1956 PROFILE:TODO-CANCEL 1957 PROFILE-VERSION:1.0 1958 VERSION:2.0 1959 PRODID:-//ACME/DesktopCalendar//EN 1960 BEGIN:VTODO 1961 COMMENT:As discussed in class, you are all off the hook! 1962 SEQUENCE:2 1963 UID:0981234-1234234-2300 1964 STATUS:CANCELLED 1965 DTSTAMP:19970717T200000Z 1966 END:VTODO 1967 END:VCALENDAR 1969 4.1.4 A Rich Published To-Do 1971 This example describes the same to-do as in 4.1.1, but in much 1972 greater detail. 1974 BEGIN:VCALENDAR 1976 BEGIN:VTIMEZONE 1977 DAYLIGHT:TRUE 1978 DTSTART:19970406T000000 1979 RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY 1980 TZNAME:CDT 1981 TZOFFSET:-0500 1982 TTRANS:020000 1983 END:VTIMEZONE 1985 BEGIN:VTIMEZONE 1986 DAYLIGHT:FALSE 1987 DTSTART:19970101T000000 1988 RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY 1989 TZNAME:CST 1990 TZOFFSET:-0600 1991 TTRANS:020000 1992 END:VTIMEZONE 1994 PRODID:-//ACME/DesktopCalendar//EN 1995 PROFILE:TODO-PUBLISH 1996 PROFILE-VERSION:1.0 1997 CALSCALE:GREGORIAN 1998 SOURCE:http://www.acmeu.edu/courses/eng-lit-101/Fall97-to-dos.or4 2000 Dawson/Hopson/Mansour/Silverberg 33 Expires January 1998 2001 NAME:English Literature 101 Course Calendar 2002 VERSION:2.0 2004 BEGIN:VTODO 2005 ATTACH:http://www.midwaystadium.com/courses/eng-lit-101/ 2006 CATEGORIES:EDUCATION;COURSE-ASSIGNMENT 2007 CLASS:PRIVATE 2008 CREATED:19970415T194319Z 2009 DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:Book Report = 2010 1=0A=0D= 2011 Fiction=0A=0D= 2012 Dr. Ling must approve the book you choose=0A=0D= 2013 book report structure can be found on:= 2014 http://www.acmeu.com/courses/eng-lit-101/bookreports.html 2015 DTSTART:19970901T210000Z 2016 DUE:19971005T200000Z 2017 COMPLETED:19971005T150000Z 2018 DTSTAMP:19970717T200000Z 2019 SEQUENCE:2 2020 UID:0981234-1234234-2300 2021 LAST-MODIFIED:19971005T132421Z 2022 RESOURCES:COMPUTER,PRINTER 2023 LOCATION;VALUE=URL:http://www.acmeu.com/campusmaps/haaghall.html 2024 PRIORITY:2 2025 SEQUENCE:3 2026 SUMMARY:Book Report on Fiction Novel 2027 UID:0981234-1234234-2300 2028 STATUS:NEEDS-ACTION 2029 RELATED-TO:0981234-1234234-1400 2031 BEGIN:VALARM 2032 DTSTART:19970910T190000Z 2033 REPEAT:2 2034 DURATION:PT2H 2035 CATEGORIES:DISPLAY,AUDIO 2036 DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:Book report 2037 rough draft 2038 END:VALARM 2040 BEGIN:VALARM 2041 DTSTART:19970930T153000 2042 CATEGORIES:DISPLAY,AUDIO 2043 DESCRIPTION:You should be reviewing your final book report draft. 2044 END:VALARM 2046 END:VTODO 2047 END:VCALENDAR 2049 The CLASS property is specified, though it is not really needed here. 2050 Since this is a published to-do, a program that displays it need not 2051 apply any content filtering based on the CLASS attribute. If this to- 2052 do is copied into a users calendar, the CLASS would be included as 2054 Dawson/Hopson/Mansour/Silverberg 34 Expires January 1998 2055 part of the copy. The handling of the CLASS tag at that point is 2056 implementation specific. 2058 The RELATED-TO field contains the UID of a related calendar to-do or 2059 event. The handling of this property is application dependent. 2061 VTIMEZONE components are discussed in detail in iTIP Part 1. 2063 The sequence number 3 indicates that this to-do supersedes versions 2064 0, 1, and 2. 2066 4.2 Group To-Do Examples 2068 Group to-dos are distinguished from published to-dos in that there is 2069 interaction between the attendees with respect to the to-do. 2070 Individual "A" creates a group task in which individuals "A", "B", 2071 "C" and "D" will participate. Individual "B" confirms acceptance of 2072 the task. Individual "C" declines the task. Individual "D" 2073 tentatively accepts the task. The following table illustrates the 2074 sequence of messages that would be exchanged between these 2075 individuals. The table below illustrates the message flow. 2077 Action Organizer Attendee 2079 Initiate a "A" sends TODO- 2080 to-do REQUEST message 2081 request to "B", "C", and 2082 "D" 2084 Accept the "B" sends TODO- 2085 to-do REPLY message to 2086 request "A" with its 2087 ATTENDEE/STATUS 2088 property parameter 2089 set to "ACCEPTED" 2091 Decline the "C" sends TODO- 2092 to-do REPLY message to 2093 request "A" with its 2094 ATTENDEE/STATUS 2095 property parameter 2096 set to "DECLINED" 2098 Tentatively "D" sends TODO- 2099 accept the REPLY message to 2100 to-do "A" with its 2101 request ATTENEE/STATUS 2102 property parameter 2103 set to "TENTATIVE" 2105 Confirm to- "A" sends TODO- 2107 Dawson/Hopson/Mansour/Silverberg 35 Expires January 1998 2108 do status REQUEST message 2109 with to "B" and "C" 2110 attendees with current 2111 information for 2112 to-do. SEQUENCE 2113 property is "1". 2115 4.2.1 A To-Do Request 2117 A sample to-do request that "A" sends to "B", "C", and "D". 2119 BEGIN:VCALENDAR 2120 PRODID:-//ACME/DesktopCalendar//EN 2121 PROFILE:TO-DO-REQUEST 2122 PROFILE-VERSION:1.0 2123 VERSION:2.0 2124 BEGIN:VTODO 2125 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com 2126 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com 2127 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com 2128 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:D@acme.com 2129 DTSTART:19970701T100000-0700 2130 DUE:19970722T100000-0700 2131 SUMMARY:Create the requirements document 2132 UID:www.acme.com-873970198738777-00 2133 SEQUENCE:0 2134 DTSTAMP:19970717T200000Z 2135 STATUS:NEEDS-ACTION 2136 END:VTODO 2137 END:VCALENDAR 2139 Note that the conference room does not have a valid e-mail address. 2141 4.2.2 A To-Do Reply 2143 Attendee "B" accepts the meeting. 2145 BEGIN:VCALENDAR 2146 PRODID:-//ACME/DesktopCalendar//EN 2147 PROFILE:TODO-REPLY 2148 PROFILE-VERSION:1.0 2149 VERSION:2.0 2150 BEGIN:VTODO 2151 ATTENDEE;STATUS=ACCEPTED:B@acme.com 2152 UID:www.acme.com-873970198738777-00 2153 COMMENT:I'll send you my input by e-mail 2154 SEQUENCE:0 2155 RESPONSE-SEQUENCE:0 2156 DTSTAMP:19970717T200000Z 2157 REQUEST-STATUS:0;Success 2158 END:VTODO 2160 Dawson/Hopson/Mansour/Silverberg 36 Expires January 1998 2161 END:VCALENDAR 2163 "B" could have declined the meeting or indicated tentative acceptance 2164 by setting the ATTENDEE;STATUS parameter to DECLINED or TENTATIVE, 2165 respectively. 2167 4.2.3 Update A To-do 2169 The to-do is moved to a different time. The combination of the UID 2170 (which remains the same) and the SEQUENCE (bumped to 1) properties 2171 indicate the update. 2173 BEGIN:VCALENDAR 2174 PRODID:-//ACME/DesktopCalendar//EN 2175 PROFILE:TODO-REQUEST 2176 PROFILE-VERSION:1.0 2177 VERSION:2.0 2178 BEGIN:VTO-DO 2179 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com 2180 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com 2181 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com 2182 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:D@acme.com 2183 DTSTART:19970701T110000-0700 2184 DUE:19970722T100000-0700 2185 COMPLETED:19970720T090000-0700 2186 DTSTAMP:19970717T200000Z 2187 STATUS:COMPLETED 2188 SUMMARY:Create the requirements document 2189 UID:www.acme.com-873970198738777 2190 SEQUENCE:1 2191 END:VTODO 2192 END:VCALENDAR 2194 4.3 Recurring To-do and Time Zone Examples 2196 4.3.1 A Recurring To-do That Spans Timezones 2198 This to-do describes a weekly status report. The attendees are each 2199 in a different timezone. 2201 BEGIN:VCALENDAR 2203 BEGIN:VTIMEZONE 2204 DAYLIGHT:TRUE 2205 DTSTART:19970406T000000 2206 RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY 2207 TZNAME:PDT 2208 TZOFFSET:-0700 2209 TTRANS:020000 2210 END:VTIMEZONE 2212 Dawson/Hopson/Mansour/Silverberg 37 Expires January 1998 2213 BEGIN:VTIMEZONE 2214 DAYLIGHT:FALSE 2215 DTSTART:19970126T000000 2216 RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY 2217 TZNAME:PST 2218 TZOFFSET:-0800 2219 TTRANS:020000 2220 END:VTIMEZONE 2222 PRODID:-//ACME/DesktopCalendar//EN 2223 PROFILE:TODO-REQUEST 2224 VERSION:2.0 2226 BEGIN:VTODO 2227 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:sman@mcom.com 2228 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:gb@mcom.fr 2229 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:kimiko@mcom.jp 2230 DTSTART:19970701T140000 2231 DUE:19970701T150000 2232 RRULE:INTERVAL=20;WKST=SU;BYDAY=TU;FREQ=WEEKLY 2233 RDATE:19970910T140000 2234 EXDATE:19970909T140000 2235 EXDATE:19971028T150000 2236 SUMMARY:Weekly Status Report 2237 UID:www.acme.com-873970198738777 2238 SEQUENCE:0 2239 DTSTAMP:19970601T200000Z 2240 STATUS:NEEDS-ACTION 2241 END:VTODO 2243 END:VCALENDAR 2245 Timezone components should appear in an iCalendar Object containing 2246 recurring to-dos. This is especially important if a recurring to-do 2247 has attendees in different timezones. There can be multiple VTIMEZONE 2248 components in an iCalendar Object. However, they must be used to 2249 define the same timezone. That is, there cannot be VTIMEZONE 2250 components describing both PST/PDT and EST/EDT at the component level 2251 in the same iCalendar Object. 2253 The first two components of this iCalendar Object are the timezone 2254 components. The DTStart date coincides with the first instance of the 2255 RRULE property. 2257 The recurring to-do is defined in a particular timezone, presumably 2258 that of the creator. The client for each attendee has the 2259 responsibility of determining the recurrence time in the attendee's 2260 timezone. 2262 The first instance of the to-do starts on Tuesday, July 1, 1997 at 2263 2:00pm. Since no timezone is specified in the DTSTART property, the 2264 timezone component of PDT applies to the start and end times. 2265 Attendee gb@mcom.fr is in France where the local time on this date is 2267 Dawson/Hopson/Mansour/Silverberg 38 Expires January 1998 2268 7 hours later than PDT or 21:00. Attendee kimiko@mcom.jp is in Japan 2269 where local time is 9 hours ahead of than UTC or Wednesday, July 2 at 2270 07:00. The to-do repeats weekly on Tuesdays (in PST/PDT). The RRULE 2271 results in 20 instances. The last instance falls on Tuesday, November 2272 11, 1997 2:00pm PST. The RDATE adds another instance: WED, 10-SEP- 2273 1997 21:00 GMT. 2275 There are two exceptions to this recurring appointment. The first one 2276 is: 2278 TUE, 09-SEP-1997 21:00 GMT 2279 TUE, 09-SEP-1997 14:00 PDT 2280 WED, 10-SEP-1997 07:00 JDT 2282 and the second is: 2284 TUE, 28-OCT-1997 22:00 GMT 2285 TUE, 28-OCT-1997 14:00 PST 2286 WED, 29-OCT-1997 07:00 JST 2288 4.3.2 Creating an Exception to a Recurring To-Do 2290 The following example illustrates a scenario where a to-do organizer 2291 changes an instance of an existing recurring to-do. In this case the 2292 organizer is changing the start and end time. 2294 Original Request: 2296 BEGIN:VCALENDAR 2297 PROFILE:TODO-REQUEST 2298 PRODID:-//RDU Software//NONSGML HandCal//EN 2299 VERSION:2.0 2300 BEGIN:VTODO 2301 CREATED:19970526T083000 2302 UID:guid-1.host1.com-001 2303 SEQUENCE:0 2304 RRULE:BYMONTHDAY=1;FREQ=MONTHLY 2305 ATTENDEE;ROLE=ORGANIZER;STATUS=ACCEPTED:Sman@netscape.com 2306 ATTENDEE;RSVP=YES:fdawson@earthlink.net 2307 ATTENDEE;RSVP=YES:Deriks@Microsoft.com 2308 ATTENDEE;RSVP=YES:Alecd@Microsoft.com 2309 DESCRIPTION:IETF-C&S Conference Call 2310 CLASS:PUBLIC 2311 SUMMARY:Merge document updates 2312 DTSTART:19970601T210000Z 2313 DUE:19970601T220000Z 2314 LOCATION:Conference Call 2315 DTSTAMP:19970601T200000Z 2316 STATUS:NEEDS-ACTION 2317 END:VTODO 2318 END:VCALENDAR 2320 Dawson/Hopson/Mansour/Silverberg 39 Expires January 1998 2321 To-do Request to change a time and create an exception: 2323 BEGIN:VCALENDAR 2324 PROFILE:TODO-REQUEST 2325 PRODID:-//RDU Software//NONSGML HandCal//EN 2326 VERSION:2.0 2327 BEGIN:VTODO 2328 UID:guid-1.host1.com-001 2329 SEQUENCE:1 2330 RECURRENCE-ID:19970701T210000Z 2331 DTSTART:19970703T210000Z 2332 DUE:19970703T220000Z 2333 DTSTAMP:19970701T200000Z 2334 END:VTODO 2335 END:VCALENDAR 2337 4.3.3 Modify Exception 2339 In this example the organizer has already created an exception and 2340 now wishes to make additional property modification. The organizer 2341 must use both the RECURRENCE-ID and UID to reference the exception. 2343 BEGIN:VCALENDAR 2344 PROFILE:TODO-REQUEST 2345 PRODID:-//RDU Software//NONSGML HandCal//EN 2346 VERSION:2.0 2347 BEGIN:VTODO 2348 UID:guid-1.host1.com-001 2349 SEQUENCE:2 2350 RECURRENCE-ID:19970701T210000Z 2351 ATTENDEE;EXPECT=REQUEST:Sman@netscape.com 2352 ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net 2353 ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com 2354 ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com 2355 ATTENDEE;EXPECT=REQUEST:RHopson@dev.davinci.com 2356 DESCRIPTION:Emergency Meeting 2357 CLASS:Private 2358 DTSTAMP:19970701T200000Z 2359 STATUS:NEEDS-ACTION 2360 END:VTODO 2361 END:VCALENDAR 2363 This example changes the specific instance properties without changing 2364 the recurring meeting parent. 2366 4.3.4 Cancel an Exception 2368 In the following example, the organizer has created an exception as 2369 in 4.3.2 and now wishes to cancel it. In this case a TODO-CANCEL is 2370 sent with the specific RECURRENCE-ID and UID of the exception. 2372 Dawson/Hopson/Mansour/Silverberg 40 Expires January 1998 2373 BEGIN:VCALENDAR 2374 PROFILE:TODO-CANCEL 2375 PRODID:-//RDU Software//NONSGML HandCal//EN 2376 VERSION:2.0 2377 BEGIN:VTODO 2378 UID:guid-1.host1.com-001 2379 RECURRENCE-ID:19970701T210000Z 2380 SEQUENCE:2 2381 DTSTAMP:19970701T200000Z 2382 STATUS:CANCELLED 2383 END:VTODO 2384 END:VCALENDAR 2386 4.3.5 Cancel Recurring To-Do 2388 In this example the organizer wishes to cancel the entire recurring 2389 to-do and any child exceptions. 2391 BEGIN:VCALENDAR 2392 PROFILE:TODO-CANCEL 2393 PRODID:-//RDU Software//NONSGML HandCal//EN 2394 VERSION:2.0 2395 BEGIN:VTODO 2396 UID:guid-1.host1.com-001 2397 SEQUENCE:2 2398 DTSTAMP:19970701T200000Z 2399 STATUS:CANCELLED 2400 END:VTODO 2401 END:VCALENDAR 2403 4.3.6 Decline A Previously Accepted Exception 2405 In this example a recipient has accepted a TODO-REQUEST which is 2406 actually an exception. The recipient now wishes to decline after 2407 previously accepting 2409 Recipient initially accepts to-do request: 2411 BEGIN:VCALENDAR 2412 PROFILE:TODO-REPLY 2413 VERSION:2.0 2414 PRODID:-//ABC Corporation//NONSGML My Product//EN 2415 BEGIN:VTODO 2416 SEQUENCE:1 2417 RESPONSE-SEQUENCE:1 2418 UID:guid-1.host1.com-001 2419 RECURRENCE-ID:19970701T210000Z 2420 ATTENDEE;STATUS=CONFIRMED:Deriks@Microsoft.com 2421 REQUEST-STATUS:0;Success 2422 DTSTAMP:19970701T200000Z 2423 RESPONSE-SEQUENCE:0 2424 END:VTODO 2426 Dawson/Hopson/Mansour/Silverberg 41 Expires January 1998 2427 END:VCALENDAR 2429 Recipient later wishes to decline the request to a recurring 2430 exception: 2432 BEGIN:VCALENDAR 2433 PROFILE:TODO-REPLY 2434 VERSION:2.0 2435 PRODID:-//ABC Corporation//NONSGML My Product//EN 2436 BEGIN:VTODO 2437 SEQUENCE:0 2438 RESPONSE-SEQUENCE:1 2439 UID:guid-1.host1.com 2440 RECURRENCE-ID:19970701T210000Z 2441 ATTENDEE;STATUS=Declined:Deriks@Microsoft.com 2442 REQUEST-STATUS:0;Success 2443 DTSTAMP:19970702T200000Z 2444 END:VTODO 2445 END:VCALENDAR 2447 5. Application Protocol Fallbacks 2449 Applications that support iTIP are not required to support the entire 2450 protocol. The following describes how profiles and properties should 2451 "fallback" in applications that do not support the complete protocol. 2452 If a profile or property is not addressed in this section, it may be 2453 safely ignored. 2455 5.1 ICalendar Profile Types 2457 Profile Fallback 2459 TODO-PUBLISH Required. 2461 TODO-CANCEL Required. 2463 TODO-REQUEST TODO-PUBLISH 2465 TODO-REPLY Required. 2467 5.2 Calendar Components 2469 Component Fallback 2471 VALARM Reply with Not Supported. 2473 Dawson/Hopson/Mansour/Silverberg 42 Expires January 1998 2474 VTIMEZONE Required if RRULE or RDATE is 2475 implemented; otherwise ignore and use 2476 local time. 2478 5.3 Calendar Properties 2480 Property Fallback 2482 CALSCALE Ignore; assume GREGORIAN. 2484 GEO Ignore. 2486 PRODID Ignore. 2488 PROFILE Required as described in the Profiles 2489 section above. 2491 PROFILE- Assume "1.0". 2492 VERSION 2494 SOURCE Ignore 2496 NAME Ignore. 2498 VERSION Assume "2.0". 2500 5.4 Component Properties 2502 Property Fallback 2504 ATTACH Ignore. 2506 ATTENDEE Required if TODO-REQUEST is not 2507 implemented; otherwise ignore. 2509 CATEGORIES Ignore. 2511 CLASS Ignore. 2513 COMMENT Ignore. 2515 COMPLETED Required. 2517 Dawson/Hopson/Mansour/Silverberg 43 Expires January 1998 2518 CREATED Ignore. 2520 DAYLIGHT Required if VTIMEZONE is implemented; 2521 otherwise ignore. 2523 DESCRIPTION Required. 2525 DUE Required. 2527 DURATION Ignore. Reply with Not Supported. 2529 DTSTART Required. 2531 EXDATE Ignore. Reply with Not Supported. 2533 EXRULE Ignore. Reply with Not Supported. 2535 LAST- Ignore. 2536 MODIFIED 2538 LOCATION Ignore. 2540 PRIORITY Required. 2542 RELATED-TO Ignore. 2544 RDATE Ignore. If implemented, VTIMEZONE must 2545 also be implemented. 2547 RRULE Ignore. The first instance occurs on 2548 the DTStart property. 2550 RESOURCES Ignore. 2552 RESPONSE- Required. 2553 SEQUENCE 2555 SEQUENCE Required. 2557 STATUS Required. 2559 SUMMARY Ignore. 2561 TRANSP Required if FREEBUSY is implemented; 2562 otherwise Ignore. 2564 TZNAME Required if VTIMEZONE is implemented; 2565 otherwise Ignore. 2567 TZOFFSET Required if VTIMEZONE is implemented; 2568 otherwise Ignore. 2570 Dawson/Hopson/Mansour/Silverberg 44 Expires January 1998 2571 TZTRANS Required if VTIMEZONE is implemented; 2572 otherwise Ignore. 2574 URL Ignore. 2576 UID Required. 2578 X- Ignore. 2580 5.5 Latency Issues 2582 With a store-and-forward transport, it is possible for requests to 2583 arrive out of sequence. That is, an implementation may receive a 2584 TODO-CANCEL notification prior to receiving the original to-do 2585 request. This section discusses a few of these scenarios. 2587 5.5.1 Cancelation of an Unknown To-do. 2589 When a TODO-CANCEL request is received before the original TODO- 2590 REQUEST the calendar will be unable to correlate the UID of the 2591 cancellation with an existing to-do. It is suggested that messages 2592 that cannot be correlated that also contain non-zero sequence numbers 2593 be held and not discarded. Implementations can age them out if no 2594 other messages arrive with the same UID and a lower sequence number. 2596 5.6 Sequence Number 2598 Under some conditions, a CUA may receive requests and replies with 2599 the same SEQUENCE number. DTSTAMP is added to act as a tiebreaker 2600 when two items with the same SEQUENCE number are evaluated. 2601 Furthermore, the SEQUENCE number is only incremented when one or more 2602 of the following properties changes: 2604 DTSTART 2606 DTEND (for Events) 2608 LOCATION 2610 DUE 2612 6. Security Considerations 2614 ITIP outlines an abstract transport protocol which will be bound to a 2615 real-time transport, a store-and-forward transport, and perhaps other 2616 transports. The transport protocol provides facilities for simple 2617 authentication using a clear text password, as well as any SASL 2618 mechanism [SASL]. SASL allows for integrity and privacy services to 2619 be negotiated. 2621 Dawson/Hopson/Mansour/Silverberg 45 Expires January 1998 2622 Use of clear text password is strongly discouraged where the 2623 underlying transport service cannot guarantee confidentiality and may 2624 result in disclosure of the password to unauthorized parties. 2626 7. Acknowledgments 2628 A hearty thanks to the following individuals who have participated in 2629 the drafting, review and discussion of this memo: 2631 Anik Ganguly, Bruce Kahn, Leo Parker, John Rose, Vinod Seraphin, 2632 Richard Shusterman, Derik Stenerson, Kevin Tsurutome. 2634 8. Bibliography 2636 [ID-DT] "Date and Time on the Internet", Internet-Draft, December 2637 1996, http://www.imc.org/draft-newman-datetime. 2639 [ICAL] "Internet Calendaring and Scheduling Core Object Specification 2640 - iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- 2641 drafts/draft-ietf-calsch-ical-02.txt. 2643 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, 2644 July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod- 2645 00.txt. 2647 [ITIP-1] "iCalendar Transport-Independent Interoperability Protocol 2648 (iTIP) - Part 1: Scheduling Events and Busytime", Internet-Draft, 2649 July 1997, http://www.imc.org/draft-ietf-calsch-itip-part1-00.txt. 2651 [ITIP-2] "iCalendar Transport-Independent Interoperability Protocol 2652 (iTIP) - Part 2: Scheduling To-dos", Internet-Draft, July 1997, 2653 http://www.imc.org/draft-ietf-calsch-itip-part2-00.txt 2655 [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", 2656 Internet-Draft, July,1996, ftp://ftp.ietf.org/internet-drafts/draft- 2657 yergeau-utf8-01.txt. 2659 [ISO8601] "Data elements and interchange formats - information 2660 interchange - Representation of dates and times", ISO 8601, 1996-06- 2661 15, +1 (212) 642-4900 for ANSI Sales. 2663 [RFC2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail 2664 Extensions - Part One - Format of Internet Message Bodies", RFC 2045, 2665 Innosoft, First Virtual, November 1996, 2666 http://www.imc.org/rfc2045.txt. 2668 [RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail 2669 Extensions - Part Two - Media Types", RFC 2046, Innosoft, First 2670 Virtual, November 1996, http://www.imc.org/rfc2046.txt. 2672 [UNICODE] The Unicode Consortium, "The Unicode Standard -Version 2673 2.0", Addison-Wesley Developers Press, July 1996. UTF-8 is described 2674 in section A-2. 2676 Dawson/Hopson/Mansour/Silverberg 46 Expires January 1998 2678 [US-ASCII] Coded Character Set--7-bit American Standard Code for 2679 Information Interchange, ANSI X3.4-1986. 2681 9. Authors Addresses 2683 The following address information is provided in a MIME-VCARD, 2684 Electronic Business Card, format. 2686 The authors of this draft are: 2688 BEGIN:VCARD 2689 FN:Frank Dawson 2690 ORG:Lotus Development Corporation 2691 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- 2692 3502;USA 2693 TEL;WORK;MSG:+1-919-676-9515 2694 TEL;WORK;FAX:+1-919-676-9564 2695 EMAIL;INTERNET:fdawson@earthlink.net 2696 URL:http://home.earthlink.net/~fdawson 2697 END:VCARD 2699 BEGIN:VCARD 2700 FN:Ross Hopson 2701 ORG:On Technology, Inc. 2702 ADR;WORK;POSTAL;PARCEL:Suite 1600;;434 Fayetteville St. 2703 Mall, Two Hannover Square;Raleigh;NC;27601 2704 TEL;WORK;MSG:+1-919-890-4036 2705 TEL;WORK;FAX:+1-919-890-4100 2706 EMAIL;INTERNET:rhopson@on.com 2707 END:VCARD 2709 BEGIN:VCARD 2710 FN:Steve Mansour 2711 ORG:Netscape Communications Corporation 2712 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 2713 View;CA;94043;USA 2714 TEL;WORK;MSG:+1-415-937-2378 2715 TEL;WORK;FAX:+1-415-428-4059 2716 EMAIL;INTERNET:sman@netscape.com 2717 END:VCARD 2719 BEGIN:VCARD 2720 FN:Steve Silverberg 2721 ORG:Microsoft Corporation 2722 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 2723 Redmond;WA;98052-6399;USA 2724 TEL;WORK;MSG:+1-206-936-9277 2725 TEL;WORK;FAX:+1-206-936-8019 2726 EMAIL;INTERNET:stevesil@Exchange.Microsoft.com 2727 END:VCARD 2729 Dawson/Hopson/Mansour/Silverberg 47 Expires January 1998 2730 The iCalendar Object is a result of the work of the Internet 2731 Engineering Task Force Calendaring and scheduling Working Group. The 2732 chairman of that working group is: 2734 BEGIN:VCARD 2735 FN:Anik Ganguly 2736 ORG:OnTime, Inc. 2737 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern 2738 Highway;Southfield;MI;48075;USA 2739 TEL;WORK;MSG:+1-810-559-5955 2740 TEL;WORK;FAX:+1-810-559-5034 2741 EMAIL;INTERNET:anik@ontime.com 2742 END:VCARD 2744 Dawson/Hopson/Mansour/Silverberg 48 Expires January 1998