idnits 2.17.1 draft-ietf-calsch-itip-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == Mismatching filename: the document gives the document name as 'draft-calsch-itip-02', but the file name used is 'draft-ietf-calsch-itip-02' ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 84 longer pages, the longest (page 44) being 66 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.) == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 16: '... that other groups MAY also distribute...' RFC 2119 keyword, line 20: '... Internet-Drafts MAY be updated, repla...' RFC 2119 keyword, line 51: '... 1 Expires MAY 1998...' RFC 2119 keyword, line 52: '... 2 Expires MAY 1998...' RFC 2119 keyword, line 53: '... 3 Expires MAY 1998...' (506 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 540 has weird spacing: '...t to an by an...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The "REQUEST" method MAY be used to delegate an event to another "Calendar User". The method is used to delegate the "Attendee's" role (i.e., "Organizer" or "Attendee") for an event. The "REQUEST" method for delegation is sent by one of the "Attendees" of an existing event request to some other "Calendar User". In order to avoid scheduling loops, the method MUST NOT be sent from an "Attendee" back to the "Organizer" of the event. An "Attendee" MAY NOT delegate to the "Organizer" of the event. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: MUST COMPONENT = CALPROPS ( MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"PUBLISH"}) MUST COMPONENT = VFREEBUSY ( MUST PROPERTY = ATTENDEE{address of originator of busy time data},FREEBUSY{values MUST all be of the same data type. Multiple instances are allowed. Multiple instances MUST be sorted in ascending order. Values MAY NOT overlap}, RELATED-TO{refers to another related VFREEBUSY == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: MUST COMPONENT = CALPROPS ( MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REPLY"}) MUST COMPONENT = VFREEBUSY ( MUST PROPERTY = ATTENDEE{address of recipient replying}, DTSTAMP, DTSTART, DTEND, FREEBUSY{values MUST all be of the same data type. Multiple instances are allowed. Multiple instances MUST be sorted in ascending order. Values MAY NOT overlap}, RELATED-TO{refers to another related VFREEBUSY component}, REQUEST-STATUS, UID MAY PROPERTY = COMMENT{comment from attendee to originator of request}, CREATED{specifies when the busy time data was created}, DTSTART{represents start of interval for busy time data}, DTEND{represents end of interval for busy time data},LAST-MODIFIED{specifies when busy time data was last modified}, SEQUENCE{IF EQ 0}, URL{specifies busy time URL} NOT PROPERTY = DURATION, SEQUENCE) MAY COMPONENT = VTIMEZONE ( MUST PROPERTY = DTSTART, TZOFFSET MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME NOT PROPERTY CREATED) MAY COMPONENT = X-TOKENS (ANY) NOT COMPONENT = VEVENT NOT COMPONENT = VTODO NOT COMPONENT = VJOURNAL NOT COMPONENT = VALARM ) == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The "REQUEST" method MAY be used to delegate or reassign ownership of a "VTODO" calendar component to another "Calendar User". The "REQUEST" method is used to delegate the "Attendee's" role (i.e. " "Organizer", or "Attendee") for a "VTODO" calendar component. The "REQUEST" method is sent by one of the "Attendees" of an existing "VTODO" calendar component request to some other individual. In order to avoid scheduling loops, the method MUST NOT be sent from an "Attendee" back to the "Organizer" of the "VTODO" calendar component. An "Attendee" of a "VTODO" calendar component MAY NOT delegate to the "Organizer" of the event. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: This document and translations of it MAY be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation MAY be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself MAY NOT be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for == 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? 'RFC1847' on line 4085 looks like a reference -- Missing reference section? 'ICMS' on line 4125 looks like a reference -- Missing reference section? 'ICAL' on line 4121 looks like a reference -- Missing reference section? 'ITIP' on line 267 looks like a reference -- Missing reference section? 'RFC 2119' on line 218 looks like a reference -- Missing reference section? 'IRIP' on line 264 looks like a reference -- Missing reference section? 'IMIP' on line 4133 looks like a reference -- Missing reference section? 'SS1' on line 2139 looks like a reference -- Missing reference section? 'SS2' on line 3216 looks like a reference -- Missing reference section? 'SS3' on line 3216 looks like a reference -- Missing reference section? 'ID-UTF8' on line 4129 looks like a reference -- Missing reference section? 'ISO8601' on line 4137 looks like a reference -- Missing reference section? 'VCAL' on line 4141 looks like a reference -- Missing reference section? 'VCARD' on line 4147 looks like a reference -- Missing reference section? 'RFC821' on line 4151 looks like a reference -- Missing reference section? 'RFC1983' on line 4155 looks like a reference -- Missing reference section? 'RFC2119' on line 4158 looks like a reference -- Missing reference section? 'RFC2045' on line 4161 looks like a reference -- Missing reference section? 'RFC2046' on line 4166 looks like a reference -- Missing reference section? 'UNICODE' on line 4170 looks like a reference -- Missing reference section? 'US-ASCII' on line 4174 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steve Silverberg, Microsoft 3 INTERNET-DRAFT Steve Mansour, Netscape 4 Calendaring and Scheduling Working Group Frank Dawson, Lotus 5 Ross Hopson, ON Technologies 6 Expires in six months from November 21,1997 8 iCalendar Transport-Independent Interoperability Protocol 9 (iTIP) 10 Scheduling Events, BusyTime, To-dos and Journal Entries 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups MAY also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts MAY be updated, replaced, or made obsolete by 21 other documents at any time. It is not appropriate to use Internet- 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Distribution of this document is unlimited. 33 Copyright (C) The Internet Society 1997. All Rights Reserved. 35 Abstract 37 This document specifies how calendaring systems use iCalendar objects 38 to interoperate with other calendar systems. It does so in a general 39 way so as to allow multiple methods of communication between systems. 40 Subsequent documents specify interoperable methods of communications 41 between systems that use this protocol. 43 The document outlines a model for calendar exchange that defines both 44 static and dynamic event, to-do, journal and free/busy objects. 45 Static objects are used to transmit information from one entity to 46 another without the expectation of continuity or referential 47 integrity with the original item. Dynamic objects are a superset of 48 static objects and will gracefully degrade to their static 49 counterparts for clients that only support static objects. 51 Silverberg/Mansour/Dawson/Hopson 1 Expires MAY 1998 52 Silverberg/Mansour/Dawson/Hopson 2 Expires MAY 1998 53 Silverberg/Mansour/Dawson/Hopson 3 Expires MAY 1998 54 Table of Contents 56 1 8 57 Introduction 9 58 1.1 Formatting Conventions 9 59 1.2 Related Documents 10 60 1.3 Calendar Roles 10 61 1.4 iTIP Transactions 11 62 2 Interoperability Models 12 63 2.1 Application Protocol 12 64 2.1.1 Calendar Entry State 13 65 3 Application Protocol Elements 13 66 3.1 Methods For "VEVENT" Calendar Component 15 67 3.1.1 PUBLISH 15 68 3.1.2 REQUEST 16 69 3.1.2.1 REQUEST for Rescheduling an Event 18 70 3.1.2.2 REQUEST for Update or Reconfirmation of an Event 18 71 3.1.2.3 REQUEST for Delegating an Event from an "Attendee" to 72 another CU 18 73 3.1.2.4 REQUEST for Delegating role of "Organizer" to another CU 19 74 3.1.2.5 REQUEST for Changing the "Organizer" from one CU to another 75 19 76 3.1.2.6 REQUEST for Changing the "Owner" 19 77 3.1.2.7 REQUEST Forwarded To An Uninvited Calendar User 20 78 3.1.2.8 REQUEST Updated Attendee Status 20 79 3.1.3 REPLY 20 80 3.1.4 CANCEL 21 81 3.1.5 REFRESH 22 82 3.1.6 COUNTER 23 83 3.1.7 DECLINECOUNTER 24 84 3.2 Methods For VFREEBUSY Component 25 85 3.2.1 PUBLISH 26 86 3.2.2 REQUEST 27 87 3.2.3 REPLY 28 88 3.3 Methods For VTODO Component 29 89 3.3.1 PUBLISH 30 90 3.3.2 REQUEST 31 91 3.3.2.1 REQUEST for Rescheduling a VTODO 32 92 3.3.2.2 REQUEST for Update or Reconfirmation of a VTODO 33 93 3.3.2.3 REQUEST for Delegating a VTODO 33 94 3.3.2.4 REQUEST Forwarded To An Uninvited Calendar User 34 95 3.3.2.5 REQUEST Updated Attendee Status 34 96 3.3.3 REPLY 35 97 3.3.4 CANCEL 36 98 3.3.5 REFRESH 37 99 3.3.6 COUNTER 37 100 3.3.7 DECLINECOUNTER 38 101 3.4 Methods For VJOURNAL Component 39 102 3.4.1 PUBLISH 40 103 3.4.2 CANCEL 41 104 3.4.3 REFRESH 41 105 3.5 Status Replies 42 107 Silverberg/Mansour/Dawson/Hopson 4 Expires MAY 1998 108 3.6 Implementation Considerations 44 109 3.6.1 Working With Recurrence Instances 44 110 3.6.2 Attendee Property Considerations 45 111 3.6.3 When To Refresh An Event 46 112 3.6.4 Timezones 46 113 3.6.5 Alarms 46 114 3.6.6 SUMMARY Property 46 115 3.6.7 X-Tokens 47 116 4 Examples 47 117 4.1 Published Event Examples 47 118 4.1.1 A Minimal Published Event 47 119 4.1.2 Changing A Published Event 48 120 4.1.3 Canceling A Published Event 49 121 4.1.4 A Rich Published Event 49 122 4.1.5 Anniversaries or Events attached to entire days 51 123 4.2 Group Event Examples 51 124 4.2.1 A Group Event Request 52 125 4.2.2 Reply To A Group Event Request 52 126 4.2.3 Update An Event 53 127 4.2.4 Countering an Event Proposal 53 128 4.2.5 Delegate An Event 55 129 4.2.6 Delegate Accepts the Meeting 58 130 4.2.7 Delegate Declines the Meeting 58 131 4.2.8 Forwarding an Event Request 59 132 4.2.9 Cancel A Group Event 59 133 4.3 Busy Time Examples 60 134 4.3.1 Request Busy Time 60 135 4.3.2 Reply To A Busy Time Request 61 136 4.4 Recurring Event and Time Zone Examples 61 137 4.4.1 A Recurring Event Spanning Time Zones 61 138 4.4.2 Modify A Recurring Instance 63 139 4.4.3 Cancel A Recurring Instance 64 140 4.4.4 Cancel An Exception 65 141 4.4.5 Cancel Recurring Event 65 142 4.4.6 Change All Future Instances 65 143 4.4.7 Add A New Instance To A Recurring Event 66 144 4.4.8 Counter An Instance Of A Recurring Event 67 145 4.4.9 Error Reply To A request 67 146 4.5 Group To-do Examples 68 147 4.5.1 A VTODO Request 69 148 4.5.2 A VTODO Reply 70 149 4.5.3 A VTODO Refresh 70 150 4.5.4 A Refresh Reply: Percent-Complete 71 151 4.5.5 A Refresh Reply: Completed 71 152 4.5.6 An Updated VTODO Request 71 153 4.5.7 A Recurring VTODOs 72 154 4.5.7.1 Request for a Recurring VTODO 72 155 4.5.7.2 Calculating due dates in recurring VTODOs 72 156 4.5.7.3 Replying to an instance of a recurring VTODO 73 157 4.6 Journal Examples 73 158 4.7 Other Examples 74 159 4.7.1 Event Refresh 74 160 4.7.2 Bad RECURRENCE-ID 74 161 5 Application Protocol Fallbacks 75 163 Silverberg/Mansour/Dawson/Hopson 5 Expires MAY 1998 164 5.1 Partial Implementation 75 165 5.1.1 Event-Related Fallbacks 76 166 5.1.2 To-Do-Related Fallbacks 77 167 5.1.3 Journal-Related Fallbacks 79 168 5.2 Latency Issues 80 169 5.2.1 Cancellation of an Unknown Calendar Component. 80 170 5.2.2 Unexpected Reply from an Unknown Delegate 80 171 5.3 Sequence Number 81 172 6 Security Considerations 81 173 6.1 Security Threats 81 174 6.1.1 Spoofing the "Organizer" 81 175 6.1.2 Spoofing the "Attendee" 82 176 6.1.3 Eavesdropping 82 177 6.1.4 Flooding a Calendar 82 178 6.1.5 Procedural Alarms 82 179 6.2 Recommendations 82 180 6.2.1 Use of [RFC1847] to secure iTIP transactions 82 181 6.2.2 Implementation Controls 83 182 7 Acknowledgments 83 183 8 Bibliography 83 184 9 Authors Addresses 84 185 10 Full Copyright Statement 85 187 1 189 Silverberg/Mansour/Dawson/Hopson 6 Expires MAY 1998 190 Introduction 192 This document specifies how calendaring systems use iCalendar objects 193 to interoperate with other calendar systems. In particular, it 194 specifies how to schedule events, to-dos, or daily journal entries. 195 It further specifies how to search for available busy time 196 information. It does so in a general way so as to allow multiple 197 methods of communication between systems. Subsequent documents 198 specify interoperable methods of communications between systems that 199 use this protocol. 201 This protocol is based on requests sent from an originator and 202 conveyed to one or more recipients. A recipient of a request MAY 203 reply, in order to update their status and MAY also return 204 transaction/request status information. The protocol also supports 205 the ability for the entry originator to modify or cancel the original 206 entry. The elements of the protocol also include the notion of user 207 roles. 209 1.1 Formatting Conventions 211 In order to refer to elements of the calendaring and scheduling 212 model, core object or interoperability protocol defined in [ICMS], 213 [ICAL] and [ITIP] several formatting conventions have been utilized. 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 217 document are to be interopreted as described in [RFC 2119]. 219 Calendaring and scheduling roles defined by [ICMS] are referred to in 220 quoted-strings of text with the first character of each word in upper 221 case. For example, "Organizer" refers to a role of a "Calendar User" 222 within the scheduling protocol defined by [ITIP] Calendar components 223 defined by [ICAL] are referred to with capitalized, quoted-strings of 224 text. All calendar components start with the letter "V". For example, 225 "VEVENT" refers to the event calendar component, "VTODO" refers to 226 the to-do calendar component and "VJOURNAL" refers to the daily 227 journal calendar component. Scheduling methods defined by [ITIP] are 228 referred to with capitalized, quoted-strings of text. For example, 229 "REQUEST" refers to the method for requesting a scheduling calendar 230 component be created or modified, "REPLY" refers to the method a 231 recipient of a request uses to update their status with the 232 "Organizer" of the calendar component. 234 Properties defined by [ICAL] are referred to with capitalized, 235 quoted-strings of text, followed by the word "property". For example, 236 "ATTENDEE" property refers to the iCalendar property used to convey 237 the calendar address of a "Calendar User". Property parameters 238 defined by this memo are referred to with lower case, quoted-strings 239 of text, followed by the word "parameter". For example, "value" 240 parameter refers to the iCalendar property parameter used to override 241 the default data type for a property value. Enumerated values defined 243 Silverberg/Mansour/Dawson/Hopson 7 Expires MAY 1998 244 by this memo are referred to with capitalized text, either alone or 245 followed by the word "value". 247 In tables, the quoted-string text is specified without quotes in 248 order to minimize the table length. 250 1.2 Related Documents 252 Implementers will need to be familiar with several other memos that, 253 along with this one, describe the Internet calendaring and scheduling 254 standards. This document, [ITIP], specifies an interoperability 255 protocol for scheduling between different implementations; 257 [ICMS] - describes the abstract model and defines common terms and 258 concepts; 260 [ICAL] - specifies the objects, data types, properties and property 261 parameters used in the protocols, along with the methods for 262 representing and encoding them; 264 [IRIP] - specifies an Internet real time protocol binding for 265 [ITIP]. 267 [IMIP] specifies an Internet email binding for [ITIP]. 269 This memo does not attempt to repeat the specification of concepts or 270 definitions from these other memos. Where possible, references are 271 made to the memo that provides for the specification of these 272 concepts or definitions. 274 1.3 Calendar Roles 276 Roles are a behavior or set of activities performed by particular 277 groups of users or agents at a given state of the calendar 278 transaction. This specification describes 4 roles that determine a 279 range of actions and responsibilities specific to each role. 281 +=====================================================================+ 282 | Role Name | Description | 283 |=====================================================================| 284 | Owner | The calendar entry owner is the only Calendar User | 285 | | allowed to directly modify an entry using the iTIP | 286 | | protocol. However, the Owner MAY delegate or | 287 | | assign an Organizer to manage the entry on their | 288 | | behalf. Usually, a calendar entry Owner is also the | 289 | | Organizer. | 290 | | | 291 | Organizer | The Organizer controls manipulation of the calendar | 292 | | entry. In most cases, the Owner and the Organizer | 293 | | are the same Calendar User. | 294 | | | 295 | Attendee | An Attendee is a Calendar User associated with | 297 Silverberg/Mansour/Dawson/Hopson 8 Expires MAY 1998 298 | | a calendar entry via a Request method issued by an | 299 | | Organizer or another Attendee. Attendees are not | 300 | | capable of directly manipulating calendar entries, | 301 | | but MUST act through the Organizer. | 302 | | | 303 | Delegate | A Delegate is a proxy that acts on behalf of another | 304 | | Calendar User. ITIP addresses two forms of | 305 | | delegation: | 306 | | 1) An Owner MAY delegate or re-assign an Organizer | 307 | | to manage a calendar entry | 308 | | 2) An Attendee MAY delegate a calendar entry request | 309 | | to another Calendar User. | 310 +=====================================================================+ 312 1.4 iTIP Transactions 314 This protocol defines seven methods for exchanging [ICAL] objects for 315 the purposes of group calendaring and scheduling between "Calendar 316 Users". The methods are defined below and their usage and semantics 317 are outlined in section 3 of this document. 319 +================+==================================================+ 320 | Method | Description | 321 |================+==================================================| 322 | PUBLISH | Used to publish a calendar entry to one or more | 323 | | Calendar Users. There is no interactivity | 324 | | between the publisher and any other calendar | 325 | | user. An example might include a baseball team | 326 | | publishing its schedule to the public. | 327 | | | 328 | REQUEST | Used to schedule a calendar entry with other | 329 | | Calendar Users. Requests are interactive in that | 330 | | they MAY require the receiver to respond using | 331 | | the the Reply methods. Meeting Requests, Busy | 332 | | Time requests and the assignment of VTODOs to | 333 | | other Calendar Users are all examples. | 334 | | Requests are also used by the "Organizer" to | 335 | | update the status of a calendar entry. | 336 | REPLY | A Reply is used in response to a Request to | 337 | | convey "Attendee" status to the "Organizer". | 338 | | Replies are commonly used to respond to meeting | 339 | | and task requests. | 340 | | | 341 | CANCEL | The Cancel method is used to cancel an existing | 342 | | calendar entry such as a VEVENT or VTODO. | 343 | | | 344 | REFRESH | The Refresh method is used by an "Attendee" to | 345 | | request the latest version of a calendar entry | 346 | | | 347 | COUNTER | The Counter method is used by an "Attendee" to | 348 | | negotiate a change in the calendar entry. | 349 | | Examples include the request to change a | 351 Silverberg/Mansour/Dawson/Hopson 9 Expires MAY 1998 352 | | proposed Event time or change the due date for a | 353 | | VTODO. | 354 | DECLINE- | | 355 | COUNTER | Used by the "Organizer" to decline the proposed | 356 | | counter-proprosal by an "Attendee" | 357 +================+==================================================+ 359 2 Interoperability Models 361 There are two distinct protocols relevant to interoperability: an 362 "Application Protocol" and a "Transport Protocol". The Application 363 Protocol defines the content of the iCalendar objects sent between 364 sender and receiver to accomplish the scheduling transactions listed 365 in section 1.4. The Transport Protocol defines how the iCalendar 366 objects are sent between the sender and receiver. This document 367 focuses on the Application Protocol. 369 The connection between Sender and Receiver in the diagram below 370 refers to the Application Protocol. In particular, the iCalendar 371 objects passed from the Sender to the Receiver which conform to those 372 presented in Section 3, Application Protocol Elements. 374 +----------+ +----------+ 375 | | iTIP | | 376 | Sender |<-------------------->| Receiver | 377 | | | | 378 +----------+ +----------+ 380 There are several variations of this diagram in which the Sender and 381 Receiver take on various roles of "CUA" or CS. These variants are 382 detailed in the Model document [ICMS] 384 The architecture of iTIP is depicted in the diagram below. An 385 application written to this specification MAY work with bindings for 386 the store-and-forward transport, the real time transport, or both. 387 Also note that iTIP could be bound to other transports. If a 388 capability is not available on a particular transport binding, iTIP 389 provides a mechanism for indicating so. 391 +------------------------------------------+ 392 | iTIP | 393 +------------------------------------------+ 394 |Real-time | Store-and-Fwd | Other | 395 |Transport | Transport | Transports... | 396 +------------------------------------------+ 398 2.1 Application Protocol 400 The model for the application protocol is centered with the 401 "Organizer" of the calendar entry. That is, the "Organizer" of a 403 Silverberg/Mansour/Dawson/Hopson 10 Expires MAY 1998 404 Calendar entry sends a request to one or more "Attendees". The 405 "Attendees" then reply to the "Organizer". The "Organizer" maintains 406 the status of the event. 408 The "Owner" is usually the "Organizer" of the calendar entry. 409 However, the "Owner" MAY delegate or assign an "Organizer" to manage 410 the calendar entry on their behalf. In cases where the "Owner" has 411 delegated to another "Organizer", the "Owner" must still be specified 412 in associated "REQUEST" and "COUNTER" methods. 414 The data sources for the application protocol are the "Calendar 415 Users". Examples of these users are the "Organizer" and "Attendees" 416 of an iCalendar event. The data objects are the iCalendar objects 417 that are exchanged between "Calendar Users". 419 2.1.1 Calendar Entry State 421 There are two distinct states relevant to calendar entries: the 422 overall state of the entry and the state associated with an 423 "Attendee" to that entry. 425 The state of an entry is defined by the "STATUS" property and is 426 controlled by the "Organizer." There is no default value for the 427 "STATUS" property. The "Organizer" MAY either set the "STATUS" 428 property to TENTATIVE or CONFIRMED values. The "Organizer" MAY also 429 set the "STATUS" property to CANCELLED value by sending a "CANCEL" 430 method to each "Attendee". 432 The state of a particular "Attendee" relative to an entry is defined 433 by the "STATUS" property parameter in the "ATTENDEE" property for 434 that "Attendee". When an "Organizer" sends out an entry, the state 435 associated with each "Attendee" is NEEDS-ACTION. Each "Attendee" MAY 436 modify their "ATTENDEE" property "STATUS" parameter to an appropriate 437 value and send it back to the "Organizer" in a "REPLY" message. 439 3 Application Protocol Elements 441 Messages are "text/calendar" MIME entities that contain calendaring 442 and scheduling information. The particular type of [ICAL] message is 443 referred to as the "method type". Each method type is identified by a 444 "METHOD" property specified as part of the "text/calendar" content 445 type. The table below shows various combinations of calendar 446 components and the method types that this memo supports. 448 +=================================================+ 449 | | VEVENT | VTODO | VJOURNAL | VFREEBUSY | 450 |=================================================| 451 |Publish | Yes | Yes | Yes | Yes | 452 |Request | Yes | Yes | No | Yes | 453 |Refresh | Yes | Yes | Yes | No | 454 |Cancel | Yes | Yes | Yes | No | 455 |Reply | Yes | Yes | No | Yes | 456 |Counter | Yes | Yes | No | No | 458 Silverberg/Mansour/Dawson/Hopson 11 Expires MAY 1998 459 |Decline- | | | | | 460 |Counter | Yes | Yes | No | No | 461 +=================================================+ 463 Each method type is defined in terms of its associated properties. 464 Some properties are required, some are optional and others are 465 excluded. The property restrictions are expressed in this memo using 466 the following formal notation: 468 prop-restriction = "(" description component method 469 1*MUST-component *MAY-component *not-component ")" 471 description = "DESCRIPTION" *ws text 472 component = "COMPONENT" *ws ("CALPROPOS" / "VEVENT" / 473 "VTODO" / "VJOURNAL") 474 method = "METHOD" *ws 477 MUST-component = "MUST COMPONENT =" *ws ("VEVENT" / "VTODO" / 478 "VJOURNAL" / "VTIMEZONE" / "VALARM" / 479 "VFREEBUSY" / "X-TOKEN") 480 *ws "(" [ws] 1*MUST-props *ws 481 *MAY-props *ws *not-props *ws ")" 483 MAY-component = "MAY COMPONENT =" *ws ("VEVENT" / "VTODO" / 484 "VJOURNAL" / "VTIMEZONE" / "VALARM" / 485 "VFREEBUSY" / "X-TOKEN") 486 *ws "(" [ws] ((*MUST-props *ws 487 *MAY-props *ws *not-props *ws) / any) ")" 489 not-component = "NOT COMPONENT =" *ws ("VEVENT" / "VTODO" / 490 "VJOURNAL" / "VTIMEZONE" / "VALARM" / 491 "VFREEBUSY" /"X-TOKEN") 493 MUST-props = "MUST PROPERTY =" *ws restriction-list 494 MAY-props = "MAY PROPERTY =" *ws (restriction-list / any) 495 not-props = "NOT PROPERTY =" *ws (restriction-list) 497 restriction-list = restriction 498 / restriction *ws "," *ws restriction 499 restriction = property-name 500 [*ws "{" parm-or-val-restriction "}"] 501 property-name = 502 parm-or-val-restriction = 505 any = "ANY" -- Specifies that any permissible 506 properties are allowed - - 508 ws = HTAB / SPACE 510 HTAB = 511 SPACE = 513 Silverberg/Mansour/Dawson/Hopson 12 Expires MAY 1998 514 3.1 Methods For "VEVENT" Calendar Component 516 This section defines the property set restrictions for the method 517 types that are applicable to the "VEVENT" calendar component. Each of 518 the methods is defined using a grammar that clarifies the property 519 constraints that define the particular method. 521 The following summarizes the methods that are defined for the 522 "VEVENT" calendar component. 524 +================+==================================================+ 525 | Method | Description | 526 |================+==================================================| 527 | PUBLISH | Post notification of an event. Used primarily as | 528 | | a method of advertising the existence of an | 529 | | event. | 530 | REQUEST | Make a request for an event. This is an explicit | 531 | | invitation to one or more "Attendees". Event | 532 | | Requests are also used to update or change an | 533 | | existing event. Clients that cannot handle | 534 | | REQUEST MAYdegrade the event to view it as an | 535 | | PUBLISH. | 536 | REPLY | Reply to an event request. Clients MAYset their | 537 | | status to | 538 | | ACCEPTED, DECLINED, TENTATIVE, DELEGATED. | 539 | CANCEL | Cancel an existing event request. | 540 | REFRESH | A request sent to an by an "Attendee" | 541 | | "Organizer" asking | 542 | | for the latest version of an event to be resent | 543 | | to the requester. | 544 | COUNTER | Counter a REQUEST with an alternative proposal. | 545 | DECLINECOUNTER | Decline a counter proposal by an "Attendee". | 546 +================+==================================================+ 548 3.1.1 PUBLISH 550 The "PUBLISH" method in a "VEVENT" calendar component provides an 551 unsolicited posting of an iCalendar object. Any "Calendar User" MAY 552 add the published components to their calendar. It requires and 553 accepts no responses to the "Organizer". Its expected usage is for 554 encapsulating an arbitrary event or to-do as an iCalendar object. The 555 "Organizer" MAY subsequently update (with another "PUBLISH" method) 556 or cancel (with a "CANCEL" method) a previously published "VEVENT" 557 calendar component. 559 This method type is an iCalendar object that conforms to the 560 following property constraints: 562 (DESCRIPTION "Event - Publish" COMPONENT "VEVENT" METHOD "PUBLISH 564 Silverberg/Mansour/Dawson/Hopson 13 Expires MAY 1998 565 MUST COMPONENT = CALPROPS ( 566 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"PUBLISH"}) 567 MUST COMPONENT = VEVENT ( 568 MUST PROPERTY = ATTENDEE{ROLE=OWNER and ORGANIZER if 569 different}, DESCRIPTION{MAY BE NULL},DTSTAMP, DTSTART, 570 SEQUENCE{IF NE 0}, UID 571 MAY PROPERTY = ATTACH, ATTENDEE{other than ROLE=OWNER | 572 ORGANIZER}, CATEGORIES, CLASS, COMMENT, 573 CREATED, DTEND, EXDATE, EXRULE, GEO, LAST-MODIFIED, 574 LOCATION,PRIORITY, RELATED-TO, RDATE, RECURRENCE-ID, 575 RESOURCES, RRULE, SEQUENCE{IF EQ 0}, 576 STATUS{TENTATIVE/CONFIRMED/CANCELLED}, 577 SUMMARY{MAYBE NULL}, URL 578 NOT PROPERTY = REQUEST-STATUS, TRANSP) 579 MAY COMPONENT = VTIMEZONE ( 580 MUST PROPERTY = DTSTART, TZOFFSET 581 MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME, 582 NOT PROPERTY = CREATED) 583 MAY COMPONENT = VALARM ( 584 MUST PROPERTY = CATEGORIES, DSTART, DURATION, REPEAT 585 MAY PROPERTY = ATTACH, DESCRIPTION, SUMMARY 586 NOT PROPERTY = COMMENT, CREATED, LAST-MODIFIED, RELATED-TO, 587 URL) 588 MAY COMPONENT = X-TOKENS (ANY) 589 NOT COMPONENT = VTODO 590 NOT COMPONENT = VJOURNAL 591 NOT COMPONENT = VFREEBUSY 592 ) 594 3.1.2 REQUEST 596 The "REQUEST" method in a "VEVENT" calendar component provides the 597 following scheduling functions: 599 . Invite "Attendees" to an event; 601 . Reschedule an existing event; 603 . Update the details of an existing event, without rescheduling 604 it; 606 . Update the status of "Attendees" of an existing event, without 607 rescheduling it; 609 . Reconfirm an existing event, without rescheduling it; 611 . For an existing "VEVENT" calendar component, delegate the role 612 of "Attendee" to another "Calendar User"; 614 . For an existing "VEVENT" calendar component, delegate the role 615 of "Organizer" to another "Calendar User". 617 Silverberg/Mansour/Dawson/Hopson 14 Expires MAY 1998 618 The originator of the "REQUEST" method is the "Organizer" of the 619 event. Normally this is the "Owner" of the event. The recipient of 620 the "REQUEST" method is the "Calendar User" invited to the event, 621 called the "Attendee". The "Attendee" uses the "REPLY" method to 622 convey their attendance status to the "Organizer" of a VEVENT 623 "REQUEST". 625 The "UID" and "SEQUENCE" properties are used to distinguish the 626 various uses of the "REQUEST" method. If the "UID" property value in 627 the "REQUEST" is not found on the recipient's calendar, then the 628 "REQUEST" is for a new "VEVENT" calendar component. If the "UID" 629 property value is found on the recipient's calendar, then the 630 "REQUEST"' is for either a rescheduling, an update, or a reconfirm of 631 the "VEVENT" calendar component. 633 If the "Organizer" of the "REQUEST" method is not authorized to make 634 an event request on the "Attendee's" calendar system, then an 635 exception is returned in the "REQUEST-STATUS" property of a 636 subsequent "REPLY" method, but no scheduling action is performed. 638 This method type is an iCalendar object that conforms to the 639 following property constraints: 641 (DESCRIPTION "Event - Request" COMPONENT "VEVENT" METHOD "REQUEST" 643 MUST COMPONENT = CALPROPS ( 644 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REQUEST"}) 645 MUST COMPONENT = VEVENT ( 646 MUST PROPERTY = ATTENDEE{ ROLE=OWNER and ORGANIZER if 647 different and "STATUS parameter absent or 648 STATUS=NEEDS-ACTION on Attendees}, DESCRIPTION{MAYBE 649 NULL}, DTSTAMP,DTSTART,SEQUENCE{IF NE 0}, UID 650 MAY PROPERTY = ATTACH, CATEGORIES, CLASS, COMMENT, CREATED, 651 DTEND, EXDATE, EXRULE, GEO, LAST-MODIFIED, LOCATION, 652 PRIORITY, RDATE, RECURRENCE-ID, RELATED-TO, RESOURCES, 653 RRULE, SEQUENCE{IF EQ 0}, STATUS{TENTATIVE/CONFIRMED 654 /CANCELLED}, SUMMARY {MAYBE NULL}, TRANSP, URL 655 NOT PROPERTY = REQUEST-STATUS) 656 MAY COMPONENT = VTIMEZONE ( 657 MUST PROPERTY = DTSTART, TZOFFSET 658 MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME 659 NOT PROPERTY = CREATED) 660 MAY COMPONENT = VALARM ( 661 MUST PROPERTY = CATEGORIES, DSTART, DURATION, REPEAT 662 MAY PROPERTY = ATTACH, DESCRIPTION, SUMMARY 663 NOT PROPERTY = COMMENT, CREATED, LAST-MODIFIED, RELATED-TO, 664 URL) 665 MAY COMPONENT = X-TOKENS (ANY) 666 NOT COMPONENT = VTODO 667 NOT COMPONENT = VJOURNAL 668 NOT COMPONENT = VFREEBUSY 669 ) 671 Silverberg/Mansour/Dawson/Hopson 15 Expires MAY 1998 672 3.1.2.1 REQUEST for Rescheduling an Event 674 The "REQUEST" method MAY be used to reschedule an event. 676 A rescheduled event involves a change to the existing event in terms 677 of it's time or recurrence intervals and possibly the location or 678 description. If the recipient "CUA" of a "REQUEST" method finds that 679 the "UID" property value already exists on the calendar, but that the 680 "SEQUENCE" property value in the "REQUEST" method is greater than the 681 value for the existing event, then the "REQUEST" method describes a 682 rescheduling of the event. 684 3.1.2.2 REQUEST for Update or Reconfirmation of an Event 686 The "REQUEST" method MAY be used to update or reconfirm an event. 688 An update to an existing event does not involve changes to the time 689 or recurrence intervals, and might not involve a change to the 690 location or description for the event. If the recipient "CUA" of a 691 "REQUEST" method finds that the "UID" property value already exists 692 on the calendar and that the "SEQUENCE" property value in the 693 "REQUEST" is the same as the value for the existing event, then the 694 "REQUEST" method describes an update of the event details, but no 695 rescheduling of the event. 697 The update "REQUEST" method is the appropriate response to a 698 "REFRESH" method sent from an "Attendee" to the "Organizer" of an 699 event. 701 Unsolicited "REQUEST" methods MAY also be sent by the "Organizer" of 702 an event. The unsolicited "REQUEST" methods MAY be used to either 703 update the details of the event, without rescheduling it, to update 704 the "STATUS" property parameter of "Attendees", or to reconfirm the 705 event. 707 3.1.2.3 REQUEST for Delegating an Event from an "Attendee" to another 708 CU 710 The "REQUEST" method MAY be used to delegate an event to another 711 "Calendar User". The method is used to delegate the "Attendee's" role 712 (i.e., "Organizer" or "Attendee") for an event. The "REQUEST" method 713 for delegation is sent by one of the "Attendees" of an existing event 714 request to some other "Calendar User". In order to avoid scheduling 715 loops, the method MUST NOT be sent from an "Attendee" back to the 716 "Organizer" of the event. An "Attendee" MAY NOT delegate to the 717 "Organizer" of the event. 719 For the purposes of this description, the "Attendee" delegating the 720 event is referred to as the "delegator". The "Attendee" receiving the 721 delegation request is referred to as the "delegatee". 723 Silverberg/Mansour/Dawson/Hopson 16 Expires MAY 1998 724 The "delegator" of an event MUST forward the existing "REQUEST" 725 method for an event to the "delegatee". The event description MUST 726 include the "delegator's" up-to-date event definition. The "REQUEST" 727 method MUST also include an "ATTENDEE" property with the calendar 728 address of the "delegatee". The "delegator" MUST also send a "REPLY" 729 method back to the "Organizer" with the "delegator's" "Attendee" 730 property "STATUS" parameter value set to DELEGATED. In addition, the 731 "DELEGATED-TO" parameter SHOULD be included with the calendar address 732 of the "delegatee". A response to the delegation "REQUEST" is sent 733 from the "delegatee" to the "Organizer" and optionally, to the 734 "delegator". The "REPLY" method from the "delegatee" SHOULD include 735 their "ATTENDEE" property with the "DELEGATED-FROM" parameter value 736 of the "delegator's"calendar address. 738 The delegation "REQUEST" method MUST assign the values of the "RSVP" 739 and "EXPECT" property parameters associated with the "delegator's" 740 "ATTENDEE" property to that of the "delegatee's" "ATTENDEE" property. 741 For example if the "delegator's" "ATTENDEE" property specifies 742 "RSVP=TRUE;EXPECT=REQUEST", then the "delegatee's" "ATTENDEE" 743 property MUST specify "RSVP=TRUE;EXPECT=REQUEST". 745 3.1.2.4 REQUEST for Delegating role of "Organizer" to another CU 747 If the "Owner" of an existing "VEVENT" calendar component wishes to 748 delegate the role of "Organizer" to another CU, they MAY issue 749 another "REQUEST" method that notifies all "Attendees" and the new 750 "Organizer" of this change. The "Owner MUST modify several property 751 parameters of the "ATTENDEE" property including the "ROLE", where the 752 role of "Owner" and "Organizer" MUST be specified. Additionally, the 753 "DELEGATED-TO" and "DELEGATED-FROM" parameters MUST specify the 754 "Organizer" and "Owner" calendar addresses. The "Owner" MAY request 755 reconfirmation by incrementing the "SEQUENCE" property and setting 756 the "RSVP" property parameter to TRUE. This will cause a 757 reconfirmation to be sent to the new organizer. 759 3.1.2.5 REQUEST for Changing the "Organizer" from one CU to another 761 An "Owner" of an existing "VEVENT" calendar component MAY change the 762 "Organizer" from one "CU" to another by sending a "REQUEST" method. 763 The "ROLE" property parameter value of ORGANIZER MUST be assigned to 764 the new "Organizer". If the old "Organizer" is still an "Attendee" 765 then "ROLE" property parameter for that "CU" MUST be set to ATTENDEE. 767 3.1.2.6 REQUEST for Changing the "Owner" 769 This memo does not support the notion of changing ownership of a 770 "VEVENT" calendar component. 772 Silverberg/Mansour/Dawson/Hopson 17 Expires MAY 1998 773 3.1.2.7 REQUEST Forwarded To An Uninvited Calendar User 775 An "Attendee" invited to an event MAY invite another uninvited 776 "Calendar User" to the event. The invited "Attendee" accomplishes 777 this scheduling action by forwarding the original "REQUEST" method to 778 the uninvited "Calendar User". The forwarded "REQUEST" method need 779 not include a new "ATTENDEE" property for the uninvited "Attendee". 780 Whether the uninvited "Calendar User" is added to the attendee list, 781 and thus informed of changes to the "VEVENT" calendar component is an 782 implementation issue. 784 3.1.2.8 REQUEST Updated Attendee Status 786 An "Organizer" of an event MAY also request an updated status from 787 one of the "Attendees". This is achieved by the "Organizer" sending a 788 "REQUEST" method to the "Attendee" with the "ATTENDEE;RSVP=TRUE" 789 property sequence. The "SEQUENCE" property for the event is not 790 changed from its previous value. A recipient will determine that the 791 only change in the "REQUEST" is that their "RSVP" property parameter 792 indicates a request for an updated status. The recipient SHOULD 793 respond with a "REPLY" method indicating their current status with 794 respect to the "REQUEST". 796 This capability MAY also be achieved by the "Organizer" sending the 797 "REFRESH" method to the "Attendees". 799 3.1.3 REPLY 801 The "REPLY" method in a "VEVENT" calendar component is used to 802 respond (e.g., accept or decline) to a request or to reply to a 803 delegation request. When used in to provide a delegation response, 804 the "delegator" SHOULD include the calendar address of the 805 "delegatee" on the "DELEGATED-TO" property parameter of the 806 "delegator's" "ATTENDEE" property. The "delegatee" SHOULD include the 807 calendar address of the "delegator" on the "DELEGATED-FROM" property 808 parameter of the "delegatee's" "ATTENDEE" property. 810 The "REPLY" method MAY also be used to respond to an unsuccessful 811 "REQUEST" method. Depending on the value of the "REQUEST-STATUS" 812 property no scheduling action MAY have been performed. 814 The "Organizer" of an event MAY receive the "REPLY" method from a 815 "Calendar User" not in the original "REQUEST". For example, a "REPLY" 816 method MAY be received from a "delegatee" to an event. In addition, 817 the "REPLY" method MAY be received from an unknown "Calendar User", 818 forwarded the "REQUEST" from an invited "Attendee". This uninvited 819 "Attendee" MAY be accepted, or the "Organizer" MAY cancel the event 820 for the uninvited "Attendee" by sending them a "CANCEL" method to the 821 univited "Attendee". 823 Silverberg/Mansour/Dawson/Hopson 18 Expires MAY 1998 824 This method type is an iCalendar object that conforms to the 825 following property constraints: 827 (DESCRIPTION "Event - Reply" COMPONENT "VEVENT" METHOD "REPLY" 829 MUST COMPONENT = CALPROPS ( 830 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REPLY"}) 831 MUST COMPONENT = VEVENT ( 832 MUST PROPERTY = ATTENDEE{MUST be address of ATTENDEE 833 replying}, DTSTAMP, SEQUENCE{IF NE 0}, UID{UID 834 associated with original REQUEST} 835 MAY PROPERTY = COMMENT{provides comment from ATTENDEE to 836 "Organizer"}, EXDATE, EXRULE, RECURRENCE-ID, REQUEST- 837 STATUS, SEQUENCE{IF EQ 0}, SUMMARY {MAYBE NULL}, URL 838 NOT PROPERTY = ATTACH, CATEGORIES, CLASS, CREATED, 839 DESCRIPTION, DTSTART, DTEND, GEO, LAST-MODIFIED, 840 PRIORITY, RELATED-TO, RESOURCES, RDATE, RRULE, STATUS, 841 SUMMARY, TRANSP, URL) 842 MAY COMPONENT = X-TOKENS (ANY) 843 NOT COMPONENT = VTODO 844 NOT COMPONENT = VJOURNAL 845 NOT COMPONENT = VFREEBUSY 846 NOT COMPONENT = VTIMEZONE 847 NOT COMPONENT = VALARM 848 ) 850 3.1.4 CANCEL 852 The "CANCEL" method in a "VEVENT" calendar component is used to send 853 a cancellation notice of an existing event request to the 854 "Attendees". The message is sent by the "Organizer" of an event to 855 the "Attendees" of the event. For a recurring event, either the whole 856 event or instances of an event MAY be cancelled. To cancel the 857 complete range of recurring event, the "UID" property value for the 858 event MUST be specified in the "CANCEL" method. In order to cancel an 859 individual instance of the event, the "RECURRENCE-ID" property value 860 for the event MUST be specified in the "CANCEL" method. In order to 861 cancel a sequence of recurring events, either the"RECURRENCE-ID" 862 property for the first event instance in the sequence MUST be 863 specified with the "RANGE" property parameter value of THISANDPRIOR 864 or THISANDFUTURE to indicate cancellation of the event instances 865 before and after the first event instance, respectively. Lastly, 866 individual recurrence instances MAY be cancelled by specifying 867 multiple"RECURRENCE-ID" properties corresponding to the instances to 868 be cancelled. 870 This method type is an iCalendar object that conforms to the 871 following property constraints: 873 (DESCRIPTION "Event - Cancel" COMPONENT "VEVENT" METHOD "CANCEL" 875 MUST COMPONENT = CALPROPS ( 876 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"CANCEL"}) 878 Silverberg/Mansour/Dawson/Hopson 19 Expires MAY 1998 879 MUST COMPONENT = VEVENT ( 880 MUST PROPERTY = DTSTAMP, SEQUENCE{IF NE 0}, UID{UID 881 associated with original REQUEST} 882 MAY PROPERTY = COMMENT{provides comment from "Organizer" to 883 ATTENDEE}, EXDATE, EXRULE, RECURRENCE-ID, SEQUENCE{IF EQ 884 0}, STATUS{CANCELLED} 885 NOT PROPERTY = ATTACH, ATTENDEE, CATEGORIES, CLASS, CREATED, 886 DESCRIPTION, DTSTART, DTEND, GEO, LAST-MODIFIED, 887 PRIORITY, RDATE, RELATED-TO, RESOURCES, REQUEST-STATUS, 888 RRULE, SUMMARY, TRANSP, URL) 889 MAY COMPONENT = X-TOKENS (ANY) 890 NOT COMPONENT = VTODO 891 NOT COMPONENT = VJOURNAL 892 NOT COMPONENT = VFREEBUSY 893 NOT COMPONENT = VTIMEZONE 894 NOT COMPONENT = VALARM 895 ) 897 3.1.5 REFRESH 899 The "REFRESH" method in a "VEVENT" calendar component is used by 900 "Attendees" of an existing event to request an updated description 901 from the event "Organizer". The "REFRESH" method MUST specify the 902 "UID" property corresponding to the event needing update. A 903 recurrence instance of an event MAY be requested by specifying the 904 "RECURRENCE-ID" property corresponding to the associated event. The 905 "Organizer" MUST respond with the latest description and version of 906 the event. This method is intended to facilitate machine processing 907 of event update requests by an "Attendee". 909 This method type is an iCalendar object that conforms to the 910 following property constraints: 912 (DESCRIPTION "Event - Refresh" COMPONENT "VEVENT" METHOD "REFRESH" 914 MUST COMPONENT = CALPROPS ( 915 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REFRESH"}) 916 MUST COMPONENT = VEVENT ( 917 MUST PROPERTY = ATTENDEE{address of requestor}, DTSTAMP, 918 SEQUENCE{IF NE 0}, UID{UID associated with original 919 REQUEST} 920 MAY PROPERTY = COMMENT{provides comment from ATTENDEE to 921 "Organizer"}, RECURRENCE-ID, SEQUENCE{IF EQ 0} 922 NOT PROPERTY = ATTACH, CATEGORIES, CLASS, CREATED, 923 DESCRIPTION, DTSTART, DTEND, EXDATE, EXRULE, GEO, 924 LAST-MODIFIED, PRIORITY, RDATE,RELATED-TO, RESOURCES, 925 REQUEST-STATUS, RRULE,SUMMARY, STATUS, TRANSP, URL) 926 MAY COMPONENT = X-TOKENS (ANY) 927 NOT COMPONENT = VTODO 928 NOT COMPONENT = VJOURNAL 929 NOT COMPONENT = VFREEBUSY 930 NOT COMPONENT = VTIMEZONE 931 NOT COMPONENT = VALARM 933 Silverberg/Mansour/Dawson/Hopson 20 Expires MAY 1998 934 ) 936 3.1.6 COUNTER 938 The "COUNTER" method in a "VEVENT" calendar component is used by an 939 "Attendee" of an existing event to submit to the "Organizer" a 940 counter proposal to the event description. The "Attendee" MUST send 941 the message to the "Organizer" of the event. 943 The counter proposal is an iCalendar object consisting of a VEVENT 944 calendar component describing the complete description of the 945 alternate event. 947 The "Organizer" rejects the counter proposal by sending the 948 "Attendee" a VEVENT "DECLINE-COUNTER" method. The "Organizer" accepts 949 the counter proposal by sending all of the "Attendees" to the event a 950 VEVENT "REQUEST" method rescheduling the event. In the later case, 951 the "Organizer" SHOULD reset the individual "RSVP" property parameter 952 values to TRUE on each "ATTENDEE" property in order to force a 953 response by the "Attendees". 955 This method type is an iCalendar object that conforms to the 956 following property constraints: 958 (DESCRIPTION "Event - Counter Proposal" COMPONENT "EVENT" 959 METHOD "COUNTER" 961 MUST COMPONENT = CALPROPS ( 962 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"COUNTER"}) 963 MUST COMPONENT = VEVENT ( 964 MUST PROPERTY = ATTENDEE{STATUS parameter absent or 965 STATUS=NEEDS ACTION, Owner and Organizer if different, 966 MAY also be used to propose other "Attendees"}, 967 DESCRIPTION{MAYBE NULL}, DTSTAMP, DTSTART, 968 SEQUENCE{IF NE 0}, UID{MUST be the UID associated with 969 the REQUEST being countered} 970 MAY PROPERTY = ATTACH, CATEGORIES, CLASS, COMMENT{provides a 971 comment from the ATTENDEE to the "Organizer"}, CREATED, 972 DTEND, EXDATE, EXRULE, GEO, LAST-MODIFIED, LOCATION, 973 PRIORITY, RDATE, RECURRENCE-ID, RELATED-TO, RESOURCES, 974 RRULE, SEQUENCE{IF EQ 0}, STATUS{TENTATIVE/CONFIRMED/ 975 CANCELLED} , SUMMARY {MAYBE NULL}, TRANSP, URL 976 NOT PROPERTY = COMPLETED, DUE, DURATION, REQUEST-STATUS) 977 MAY COMPONENT = VTIMEZONE ( 978 MUST PROPERTY = DTSTART, TZOFFSET 979 MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME 980 NOT PROPERTY = CREATED) 981 MAY COMPONENT = VALARM (IF COMPONENT EXISTS 982 MUST PROPERTY = CATEGORIES, DSTART, DURATION, REPEAT 983 MAY PROPERTY = ATTACH, DESCRIPTION, SUMMARY 984 NOT PROPERTY = COMMENT, CREATED, LAST-MODIFIED, RELATED-TO, URL) 985 MAY COMPONENT = X-TOKENS (ANY) 986 NOT COMPONENT = VTODO 988 Silverberg/Mansour/Dawson/Hopson 21 Expires MAY 1998 989 NOT COMPONENT = VJOURNAL 990 NOT COMPONENT = VFREEBUSY 991 ) 993 3.1.7 DECLINECOUNTER 995 The "DECLINE-COUNTER" method in a "VEVENT" calendar component is used 996 by the "Organizer" of an event to reject a counter proposal submitted 997 by an "Attendee". The "Organizer" MUST send the "DECLINE-COUNTER" 998 message to the "Attendee" that sent the "COUNTER" method to the 999 "Organizer". 1001 The counter proposal is an iCalendar object consisting of a VEVENT 1002 calendar component describing the complete description of the 1003 alternate event. 1005 The "Organizer" rejects the counter proposal by sending the 1006 "Attendee" a "DECLINE-COUNTER" method. The "Organizer" accepts the 1007 counter proposal by sending all of the "Attendees" to the event a 1008 "REQUEST" method; rescheduling the event. Since this is a rescheduled 1009 event, the "SEQUENCE" property value will be incremented. In the 1010 later case, the "Organizer" SHOULD reset the individual "RSVP" 1011 parameter values to TRUE on all of the "ATTENDEE" properties; in 1012 order to force a response by the "Attendees". 1014 This method type is an iCalendar object that conforms to the 1015 following property constraints: 1017 (DESCRIPTION "Event - Cancel" COMPONENT "VEVENT" METHOD 1018 "DECLINECOUNTER" 1020 MUST COMPONENT = CALPROPS ( 1021 MUST PROPERTY = PRODID, VERSION{"2.0"},METHOD{ 1022 "DECLINECOUNTER"}) 1023 MUST COMPONENT = VEVENT ( 1024 MUST PROPERTY = DTSTAMP, SEQUENCE{IF NE 0}, UID{same UID 1025 specified In Original REQUEST and subsequent COUNTER} 1026 MAY PROPERTY = COMMENT{provides comment from "Organizer" to 1027 ATTENDEE}, RECURRENCE-ID, REQUEST-STATUS, SEQUENCE{IF EQ 1028 0} 1029 NOT PROPERTY = ATTACH, ATTENDEE, CATEGORIES, CLASS, CREATED, 1030 DESCRIPTION, DTSTART, DTEND, EXDATE, EXRULE, GEO, 1031 LAST-MODIFIED, PRIORITY, RDATE, RELATED-TO, RESOURCES, 1032 RRULE,STATUS, SUMMARY, TRANSP, URL) 1033 MAY COMPONENT = X-TOKENS (ANY) 1034 NOT COMPONENT = VTODO 1035 NOT COMPONENT = VJOURNAL 1036 NOT COMPONENT = VFREEBUSY 1037 NOT COMPONENT = VTIMEZONE 1038 NOT COMPONENT = VALARM 1039 ) 1041 Silverberg/Mansour/Dawson/Hopson 22 Expires MAY 1998 1042 3.2 Methods For VFREEBUSY Component 1044 This section defines the property set for the methods that are 1045 applicable to the "VFREEBUSY" calendar component. Each of the methods 1046 is defined using a grammar that specifies the property constraints 1047 that define the particular method. 1049 This memo only addresses the transfer of busy time information. 1050 Applications desiring free time information MUST infer this from 1051 available busy time information. 1053 The busy time information within the iCalendar object MAY be grouped 1054 into more than one "VFREEBUSY" calendar component. This capability 1055 allows busy time periods to be grouped according to some common 1056 periodicity, such as a calendar week, month, or year. In this case, 1057 each "VFREEBUSY" calendar component MUST include the "ATTENDEE", 1058 "DTSTART" and "DTEND" properties in order to specify the source of 1059 the busy time information and the date and time interval over which 1060 the busy time information covers. 1062 The "FREEBUSY" property value MAY include a list of values, separated 1063 by the COMMA character (ASCII decimal 44). Alternately, multiple busy 1064 time periods MAY be specified with multiple instances of the 1065 "FREEBUSY" property. Both forms MUST be supported by implementations 1066 conforming to this document. Duplicate busy time periods SHOULD NOT 1067 be specified in an iCalendar object. However, two different busy time 1068 periods MAY overlap. 1070 "FREEBUSY" properties SHOULD be sorted such that their values are in 1071 ascending order, based on the start time, and then the end time, with 1072 the earliest periods first. For example, today's busy time 1073 information SHOULD appear after yesterday's busy time information. 1074 And the busy time for this half hour SHOULD appear after the busy 1075 time for earlier today. 1077 Since events MAY span a day boundary, free busy time period MAY also 1078 span a day boundary. Individual "A" requests busy time from 1079 individuals "B", "C" and "D". Individual "B" and "C" replies with 1080 busy time data to individual "A". Individual "D" does not support 1081 busy time requests and does not reply with any data. If the transport 1082 binding supports exception messages, then a "unsupported capability" 1083 message is returned by individual "D" to individual "A". 1085 The following summarizes the methods that are defined for the 1086 "VFREEBUSY" calendar component. 1088 |================|==================================================| 1089 | Method | Description | 1090 |================|==================================================| 1091 | PUBLISH | Publish unsolicited busy time data. | 1092 | REQUEST | Request busy time data. | 1093 | REPLY | Reply to a busy time request. | 1094 |================|==================================================| 1096 Silverberg/Mansour/Dawson/Hopson 23 Expires MAY 1998 1097 3.2.1 PUBLISH 1099 The "PUBLISH" method in a "VFREEBUSY" calendar component is used to 1100 publish busy time data. The method MAY be sent from one "Calendar 1101 User" to any other. The purpose of the method is to provide a message 1102 for sending unsolicited busy time data. That is, the busy time data 1103 is not being sent as a "REPLY" to the receipt of a "REQUEST" method. 1105 Busy time intervals are represented by individual instances of the 1106 "FREEBUSY" property. There is one occurrence of the property for each 1107 busy time interval. Duplicate busy time periods SHOULD NOT be 1108 returned. However, two different busy time periods MAY overlap. 1110 The "FREEBUSY" property value MAY include a list of values, separated 1111 by the COMA character (ASCII decimal 44). 1113 "FREEBUSY" properties SHOULD be sorted such that their values are in 1114 ascending order, from the most recent to past. For example, today's 1115 busy time information SHOULD appear after yesterday's busy time 1116 information. And the busy time for this half hour SHOULD appear after 1117 the busy time for earlier today. 1119 Since events MAY span a day boundary, free busy time period MAY also 1120 span a day boundary. 1122 The busy time periods MAY be grouped into more than one "VFREEBUSY" 1123 calendar component. This capability allows busy time periods to be 1124 grouped according to some common periodicity, such as a calendar 1125 week, month, or year. In this case, each "VFREEBUSY" calendar 1126 component MUST include the "ATTENDEE", "DTSTART" and "DTEND" 1127 properties in order to specify the originator and date and time 1128 interval for the busy time information. 1130 The "ATTENDEE" property MUST be specified in the busy time 1131 information. The value is the "Calendar User" address of the 1132 originator of the busy time information. 1134 This method type is an iCalendar object that conforms to the 1135 following property constraints: 1137 (DESCRIPTION "Busy - Busy Time Publish" COMPONENT "VFREEBUSY" 1138 METHOD "PUBLISH" 1140 MUST COMPONENT = CALPROPS ( 1141 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"PUBLISH"}) 1142 MUST COMPONENT = VFREEBUSY ( 1143 MUST PROPERTY = ATTENDEE{address of originator of busy time 1144 data},FREEBUSY{values MUST all be of the same data type. 1145 Multiple instances are allowed. Multiple instances MUST 1146 be sorted in ascending order. Values MAY NOT overlap}, 1147 RELATED-TO{refers to another related VFREEBUSY 1149 Silverberg/Mansour/Dawson/Hopson 24 Expires MAY 1998 1150 component}, 1151 MAY PROPERTY = COMMENT{comment from attendee to originator of 1152 request}, CREATED{specifies when the busy time data was 1153 created}, DTSTART{represents start of interval for busy 1154 time data}, DTEND{represents end of interval for busy 1155 time data},LAST-MODIFIED{specifies when busy time data 1156 was last modified}, SEQUENCE{IF EQ 0}, URL{specifies busy 1157 time URL} 1158 NOT PROPERTY = DTSTAMP, DURATION, REQUEST-STATUS, SEQUENCE, 1159 UID) 1160 MAY COMPONENT = VTIMEZONE ( 1161 MUST PROPERTY = DTSTART, TZOFFSET 1162 MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME 1163 NOT PROPERTY = CREATED) 1164 MAY COMPONENT = X-TOKENS (ANY) 1165 NOT COMPONENT = VEVENT 1166 NOT COMPONENT = VTODO 1167 NOT COMPONENT = VJOURNAL 1168 NOT COMPONENT = VALARM 1169 ) 1171 3.2.2 REQUEST 1173 The "REQUEST" method in a "VFREEBUSY" calendar component is used to 1174 ask a "Calendar User" for their busy time information. The request 1175 MAY be for a busy time information bounded by a specific date and 1176 time interval. 1178 This message only permits requests for busy time information. The 1179 message is sent from a "Calendar User" requesting the busy time 1180 information to one or more intended recipients. 1182 An "ATTENDEE" property MUST be included for the originator of the 1183 request and each of the intended recipients that the method is sent 1184 to. The originator is indicated with an "ATTENDEE" property parameter 1185 sequence of ";ROLE=ORGANIZER". The recipients are indicated with an 1186 "ATTENDEE" property parameter sequence of ";ROLE=ATTENDEE". The 1187 requests MAY be fanned out in separate messages to the recipients, 1188 with each "REQUEST" method only including the associated "ATTENDEE" 1189 properties for the recipients of the message. 1191 If the originator of the "REQUEST" method is not authorized to make a 1192 busy time request on the recipient's calendar system, then an 1193 exception message is returned in a "REPLY" method, but no busy time 1194 data need be returned. 1196 This method type is an iCalendar object that conforms to the 1197 following property constraints: 1199 (DESCRIPTION "FREEBUSY - Request For Busy Time" COMPONENT 1200 "VFREEBUSY" METHOD "REQUEST" 1202 MUST COMPONENT = CALPROPS ( 1204 Silverberg/Mansour/Dawson/Hopson 25 Expires MAY 1998 1205 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REQUEST"}) 1206 MUST COMPONENT = VFREEBUSY ( 1207 MUST PROPERTY = ATTENDEE{Attendee instances for the Owner and 1208 Organizer if different and the intended recipient of the 1209 request}, DTSTAMP, DTSTART, DTEND,SEQUENCE{IF NE 0}, UID 1210 MAY PROPERTY = SEQUENCE{IF EQ 0} 1211 NOT PROPERTY = COMMENT, CREATED, DURATION, FREEBUSY, 1212 LAST-MODIFIED, RELATED-TO, URL, REQUEST-STATUS) 1213 MAY COMPONENT = VTIMEZONE ( 1214 MUST PROPERTY = DTSTART, TZOFFSET 1215 MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME 1216 NOT PROPERTY = CREATED) 1217 MAY COMPONENT X-TOKENS (ANY) 1218 NOT COMPONENT = VEVENT 1219 NOT COMPONENT = VTODO 1220 NOT COMPONENT = VJOURNAL 1221 NOT COMPONENT = VALARM 1222 ) 1224 3.2.3 REPLY 1226 The "REPLY" method in a "VFREEBUSY" calendar component is used to 1227 respond to an existing busy time request. The method is sent from a 1228 recipient of a busy time request back to the originator of the 1229 request. The originator of the request is specified by the "ATTENDEE" 1230 property parameter sequence of ";ROLE=ORGANIZER". 1232 The "REPLY" method MAY also be used to respond to an unsuccessful 1233 "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy 1234 time information MAY be returned. 1236 Busy time intervals are represented by individual instances of the 1237 "FREEBUSY" property. There is one occurrence of the property for each 1238 busy time interval. Duplicate busy time periods SHOULD NOT be 1239 returned. However, two different busy time periods MAY overlap. 1241 The "FREEBUSY" property value MAY include a list of values, separated 1242 by the COMA character (ASCII decimal 44). 1244 "FREEBUSY" properties SHOULD be sorted such that their values are in 1245 ascending order, from the most recent to past. For example, today's 1246 busy time information SHOULD appear after yesterday's busy time 1247 information. And the busy time for this half hour SHOULD appear after 1248 the busy time for earlier today. 1250 Since events MAY span a day boundary, free busy time period MAY also 1251 span a day boundary. 1253 The busy time periods MAY be grouped into more than one "VFREEBUSY" 1254 calendar component. This capability allows busy time periods to be 1255 grouped according to some common periodicity, such as a calendar 1256 week, month, or year. In this case, each "VFREEBUSY" calendar 1257 component MUST include the "ATTENDEE", "DTSTART" and "DTEND" 1259 Silverberg/Mansour/Dawson/Hopson 26 Expires MAY 1998 1260 properties in order to identify the source and date and time range 1261 for the busy time data. 1263 The "ATTENDEE" property MUST be specified in the busy time reply. The 1264 value is the fully qualified RFC 822 address of the recipient 1265 replying to the busy time request. 1267 This method type is an iCalendar object that conforms to the 1268 following property constraints: 1270 (DESCRIPTION "FreeBusy - Busy Time Reply" COMPONENT "VFREEBUSY" 1271 METHOD "REPLY" 1273 MUST COMPONENT = CALPROPS ( 1274 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REPLY"}) 1275 MUST COMPONENT = VFREEBUSY ( 1276 MUST PROPERTY = ATTENDEE{address of recipient replying}, 1277 DTSTAMP, DTSTART, DTEND, FREEBUSY{values MUST all be of 1278 the same data type. Multiple instances are allowed. 1279 Multiple instances MUST be sorted in ascending order. 1280 Values MAY NOT overlap}, RELATED-TO{refers to another 1281 related VFREEBUSY component}, REQUEST-STATUS, UID 1282 MAY PROPERTY = COMMENT{comment from attendee to originator of 1283 request}, CREATED{specifies when the busy time data was 1284 created}, DTSTART{represents start of interval for busy 1285 time data}, DTEND{represents end of interval for busy 1286 time data},LAST-MODIFIED{specifies when busy time data 1287 was last modified}, SEQUENCE{IF EQ 0}, URL{specifies busy 1288 time URL} 1289 NOT PROPERTY = DURATION, SEQUENCE) 1290 MAY COMPONENT = VTIMEZONE ( 1291 MUST PROPERTY = DTSTART, TZOFFSET 1292 MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME 1293 NOT PROPERTY CREATED) 1294 MAY COMPONENT = X-TOKENS (ANY) 1295 NOT COMPONENT = VEVENT 1296 NOT COMPONENT = VTODO 1297 NOT COMPONENT = VJOURNAL 1298 NOT COMPONENT = VALARM 1299 ) 1301 3.3 Methods For VTODO Component 1303 This section defines the property set for the methods that are 1304 applicable to the "VTODO" calendar component . Each of the methods is 1305 defined using a grammar that specifies the property constraints that 1306 define the particular method. 1308 The following summarizes the methods that are defined for the "VTODO" 1309 calendar component . 1311 +================+==================================================+ 1313 Silverberg/Mansour/Dawson/Hopson 27 Expires MAY 1998 1314 | Method | Description | 1315 |================+==================================================| 1316 | PUBLISH | Post notification of a VTODO. Used primarily as | 1317 | | a method of advertising the existence of a VTODO.| 1318 | REQUEST | Assign a VTODO. This is an explicit assignment to| 1319 | | one or more Calendar Users.VTODO REQUEST method | 1320 | | is also used to update or change an existing | 1321 | | VTODO. Clients that cannot handle REQUEST MAY | 1322 | | degrade the method to view it as a PUBLISH. | 1323 | REPLY | Reply to a VTODO request. Attendees MAYset | 1324 | | status to ACCEPTED, DECLINED, TENTATIVE, | 1325 | | DELEGATED, PARTIAL, and COMPLETED. | 1326 | CANCEL | Cancel an existing VTODO assignment. | 1327 | REFRESH | A request sent to a VTODO "Organizer" asking for | 1328 | | the latest version of a | 1329 | COUNTER | Counter a REQUEST with an alternative proposal. | 1330 | DECLINECOUNTER | Decline a counter proposal by an attendee. | 1331 +================+==================================================+ 1333 3.3.1 PUBLISH 1335 The "PUBLISH" method in a "VTODO" calendar component has no reply 1336 response associated with it. Instead, it is simply a posting of an 1337 iCalendar object that MAY be added to a calendar by a "Calendar 1338 User". It requires and accepts no responses to the "Organizer". It's 1339 expected usage is for encapsulating an arbitrary "VTODO" calendar 1340 component as an iCalendar object. The "Organizer" MAY subsequently 1341 update (with another "PUBLISH" method) or cancel (with a "CANCEL" 1342 method) a previously published "VTODO" calendar component . 1344 This method type is an iCalendar object that conforms to the 1345 following property constraints: 1347 (DESCRIPTION "VTODO - Publish" COMPONENT "VTODO" METHOD "PUBLISH 1349 MUST COMPONENT = CALPROPS ( 1350 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"PUBLISH"}) 1351 MUST COMPONENT = VTODO( 1352 MUST PROPERTY = ATTENDEE{only Owner and Organizer if 1353 different}, DESCRIPTION{MAYBE NULL}, DTSTAMP, DTSTART, 1354 PRIORITY, SEQUENCE{IF NE 0}, UID 1355 MAY PROPERTY = ATTACH, ATTENDEE{other than ROLE=OWNER | 1356 ORGANIZER}, CATEGORIES, CLASS, COMMENT, CREATED, DUE, 1357 EXDATE, EXRULE, GEO, LAST-MODIFIED, LOCATION,PERCENT- 1358 COMPLETE, RELATED-TO, RDATE, RECURRENCE-ID, RESOURCES, 1359 RRULE, SEQUENCE{IF EQ 0}, STATUS{TENTATIVE/CONFIRMED 1360 /CANCELLED}, SUMMARY{MAYBE NULL}, URL 1361 NOT PROPERTY = REQUEST-STATUS) 1362 MAY COMPONENT = VTIMEZONE ( 1363 MUST PROPERTY = DTSTART, TZOFFSET 1364 MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME 1365 NOT PROPERTY = CREATED) 1367 Silverberg/Mansour/Dawson/Hopson 28 Expires MAY 1998 1368 MAY COMPONENT = VALARM ( 1369 MUST PROPERTY = CATEGORIES, DSTART, DURATION, REPEAT 1370 MAY PROPERTY = ATTACH, DESCRIPTION, SUMMARY 1371 NOT PROPERTY = COMMENT, CREATED, LAST-MODIFIED, RELATED-TO, URL) 1372 MAY COMPONENT = X-TOKENS (ANY) 1373 NOT COMPONENT = VEVENT 1374 NOT COMPONENT = VJOURNAL 1375 NOT COMPONENT = VFREEBUSY 1376 ) 1378 3.3.2 REQUEST 1380 The "REQUEST" method in a "VTODO" calendar component provides the 1381 following scheduling functions: 1383 . Assign a to-do to one or more "Calendar Users"; 1385 . Reschedule an existing to-do; 1387 . Update the details of an existing to-do, without rescheduling 1388 it; 1390 . Update the completion status of "Attendees" of an existing to- 1391 do, without rescheduling it; 1393 . Reconfirm an existing to-do, without rescheduling it; 1395 . Delegate/reassign an existing to-do to another "Calendar User". 1397 The assigned "Calendar Users" are identified in the "VTODO" calendar 1398 component by individual "ATTENDEE;ROLE=ATTENDEE" property value 1399 sequences. 1401 The originator of a "REQUEST" is the "Organizer" of the to-do. The 1402 recipient of a "REQUEST" is the "Calendar User" assigned the to-do, 1403 called the Attendee. The "Attendee" uses the "REPLY" method to convey 1404 their acceptance and completion status to the "Organizer" of the 1405 "REQUEST". 1407 The "UID" and "SEQUENCE" properties are used to distinguish the 1408 various uses of the "REQUEST" method. If the "UID" property value in 1409 the "REQUEST" is not found on the recipient's calendar, then the 1410 "REQUEST" is for a new to-do. If the "UID" property value is found on 1411 the recipient's calendar, then the "REQUEST" is for either a 1412 rescheduling, an update, or a reconfirm of the "VTODO" calendar 1413 object. 1415 If the "Organizer" of the "REQUEST" method is not authorized to make 1416 a to-do request on the "Attendee's" calendar system, then an 1417 exception is returned in the "REQUEST-STATUS" property of a 1418 subsequent "REPLY" method, but no scheduling action is performed. 1420 Silverberg/Mansour/Dawson/Hopson 29 Expires MAY 1998 1421 This method type is an iCalendar object that conforms to the 1422 following property constraints: 1424 (DESCRIPTION "VTODO - Request" COMPONENT "VTODO" METHOD "REQUEST" 1426 MUST COMPONENT = CALPROPS ( 1427 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REQUEST"}) 1428 MUST COMPONENT = VTODO( 1429 MUST PROPERTY = ATTENDEE{For Owner and Organizer if different 1430 and each Attendee},DESCRIPTION{MAYBE NULL}, DTSTAMP, 1431 DTSTART, PRIORITY, SEQUENCE{IF NE 0}, UID 1432 MAY PROPERTY = ATTACH, CATEGORIES, CLASS, COMMENT, 1433 CREATED, DUE, EXDATE, EXRULE, GEO, LAST-MODIFIED, 1434 LOCATION, PERCENT-COMPLETE, RELATED-TO, RDATE, 1435 RECURRENCE-ID, RESOURCES, RRULE, SEQUENCE{IF EQ 0}, 1436 STATUS{TENTATIVE/CONFIRMED/CANCELLED}, SUMMARY{MAYBE 1437 NULL}, URL 1438 NOT PROPERTY = REQUEST-STATUS) 1439 MAY COMPONENT = VTIMEZONE ( 1440 MUST PROPERTY = DTSTART, TZOFFSET 1441 MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME 1442 NOT PROPERTY = CREATED) 1443 MAY COMPONENT = VALARM ( 1444 MUST PROPERTY = CATEGORIES, DSTART, DURATION, REPEAT 1445 MAY PROPERTY = ATTACH, DESCRIPTION, SUMMARY 1446 NOT PROPERTY = COMMENT, CREATED, LAST-MODIFIED, RELATED-TO, 1447 URL) 1448 MAY COMPONENT = X-TOKENS (ANY) 1449 NOT COMPONENT = VEVENT 1450 NOT COMPONENT = VJOURNAL 1451 NOT COMPONENT = VFREEBUSY 1452 ) 1454 3.3.2.1 REQUEST for Rescheduling a VTODO 1456 The "REQUEST" method MAY be used to reschedule a "VTODO" calendar 1457 component . 1459 A rescheduled "VTODO" calendar component involves a change to the 1460 existing "VTODO" calendar component in terms of it's start or due 1461 time or recurrence intervals and possibly the description. If the 1462 recipient "CUA" of a "REQUEST" method finds that the "UID" property 1463 value already exists on the calendar, but that the "SEQUENCE" 1464 property value in the "REQUEST" is greater than the value for the 1465 existing VTODO, then the "REQUEST" method describes a rescheduling of 1466 the "VTODO" calendar component. 1468 Silverberg/Mansour/Dawson/Hopson 30 Expires MAY 1998 1469 3.3.2.2 REQUEST for Update or Reconfirmation of a VTODO 1471 The "REQUEST" method MAY be used to update or reconfirm a "VTODO" 1472 calendar component. Reconfirmation is merely an update of "Attendee" 1473 completion status or overall "VTODO" calendar component status. 1475 An update to an existing "VTODO" calendar component does not involve 1476 changes to the start or due time or recurrence intervals, nor 1477 generally to the description for the "VTODO" calendar component. If 1478 the recipient "CUA" of a "REQUEST" method finds that the "UID" 1479 property value already exists on the calendar and that the "SEQUENCE" 1480 property value in the "REQUEST" is the same as the value for the 1481 existing event, then the "REQUEST" method describes an update of the 1482 "VTODO" calendar component details, but no rescheduling of the 1483 "VTODO" calendar component. 1485 The update "REQUEST" is the appropriate response to a "REFRESH" 1486 method sent from an "Attendee" to the "Organizer" of a "VTODO" 1487 calendar component. 1489 Unsolicited "REQUEST" methods MAY also be sent by the "Organizer" of 1490 a "VTODO" calendar component. The unsolicited "REQUEST" methods MAY 1491 be used to either update the details of the VTODO, without 1492 rescheduling it or to update the completion status of "Attendees" or 1493 the "VTODO" calendar component itself (i.e., reconfirm the VTODO). 1495 3.3.2.3 REQUEST for Delegating a VTODO 1497 The "REQUEST" method MAY be used to delegate or reassign ownership of 1498 a "VTODO" calendar component to another "Calendar User". The 1499 "REQUEST" method is used to delegate the "Attendee's" role (i.e. " 1500 "Organizer", or "Attendee") for a "VTODO" calendar component. The 1501 "REQUEST" method is sent by one of the "Attendees" of an existing 1502 "VTODO" calendar component request to some other individual. In order 1503 to avoid scheduling loops, the method MUST NOT be sent from an 1504 "Attendee" back to the "Organizer" of the "VTODO" calendar component. 1505 An "Attendee" of a "VTODO" calendar component MAY NOT delegate to the 1506 "Organizer" of the event. 1508 For the purposes of this description, the "Attendee" delegating the 1509 "VTODO" calendar component is referred to as the "delegator". The 1510 "Attendee" receiving the delegation request is referred to as the 1511 "delegatee". 1513 The "delegator" of a "VTODO" calendar component MUST forward the 1514 existing "REQUEST" method for a "VTODO" calendar component to the 1515 "delegatee". The "VTODO" calendar component description MUST include 1516 the "delegator's" up-to-date "VTODO" calendar component definition. 1517 The "REQUEST" method MUST also include an "ATTENDEE" property with 1518 the calendar address of the "delegatee". The "delegator" MUST also 1519 send a "REPLY" method back to the "Organizer" with the "delegator's" 1520 "Attendee" property "STATUS" parameter value set to DELEGATED. In 1522 Silverberg/Mansour/Dawson/Hopson 31 Expires MAY 1998 1523 addition, the "DELEGATED-TO" parameter SHOULD be included with the 1524 calendar address of the "delegatee". A response to the delegation 1525 "REQUEST" is sent from the "delegatee" to the "Organizer" and 1526 optionally, to the "delegator". The "REPLY" method from the 1527 "delegatee" SHOULD include the "ATTENDEE" property with their 1528 calendar address and the "DELEGATED-FROM" parameter with the value of 1529 the "delegator's"calendar address. 1531 The delegation "REQUEST" method MUST assign the values of the "RSVP" 1532 and "EXPECT" property parameters associated with the "delegator's" 1533 "Attendee" property to that of the "delegatee's" "Attendee" property. 1534 For example if the "delegator's" "Attendee" property specifies 1535 "RSVP=TRUE;EXPECT=REQUEST", then the "delegatee's" "Attendee" 1536 property MUST specify "RSVP=TRUE;EXPECT=REQUEST". 1538 3.3.2.4 REQUEST Forwarded To An Uninvited Calendar User 1540 An "Attendee" assigned a "VTODO" calendar component MAY also assign 1541 the "VTODO" calendar component to another new "Calendar User", not 1542 previously associated with the "VTODO" calendar component. The 1543 current "Attendee" assigned the "VTODO" calendar component 1544 accomplishes this scheduling action by forwarding the original 1545 "REQUEST" method to the new "Calendar User". 1547 An "Organizer" of a "VTODO" calendar component MAY also request an 1548 updated completion status from one of the "Attendees". This is 1549 achieved by the "Organizer" sending a "REQUEST" method to the 1550 "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The 1551 "SEQUENCE" property for the "VTODO" calendar component is not changed 1552 from its previous value. A recipient will determine that the only 1553 change in the "REQUEST" is that their "RSVP" property parameter 1554 indicates a request for an updated status. The recipient SHOULD 1555 respond with a "REPLY" method indicating their current status with 1556 respect to the "REQUEST". 1558 3.3.2.5 REQUEST Updated Attendee Status 1560 An "Organizer" of a to-do MAY also request an updated status from one 1561 of the "Attendees". This is achieved by the "Organizer" sending a 1562 "REQUEST" method to the "Attendee" with the "ATTENDEE;RSVP=TRUE" 1563 property sequence. The "SEQUENCE" property for the to-do is not 1564 changed from its previous value. A recipient will determine that the 1565 only change in the "REQUEST" is that their "RSVP" property parameter 1566 indicates a request for an updated status. The recipient SHOULD 1567 respond with a "REPLY" method indicating their current status with 1568 respect to the "REQUEST". 1570 This capability MAY also be achieved by the "Organizer" sending the 1571 "REFRESH" method to the "Attendees". 1573 Silverberg/Mansour/Dawson/Hopson 32 Expires MAY 1998 1574 3.3.3 REPLY 1576 The "REPLY" method in a "VTODO" calendar component is used to respond 1577 (e.g., accept or decline) to a request or to reply to a delegation 1578 request. It is also used by an "Attendee" to update their completion 1579 status. When used to provide a delegation response, the "delegator" 1580 SHOULD include the calendar address of the "delegatee" in the 1581 "DELEGATED-TO" parameter of the "delegator's" "ATTENDEE" property. 1582 The "delegatee" SHOULD include the calendar address of the 1583 "delegator" on the "DELEGATED-FROM" parameter of the "delegatee's" 1584 "ATTENDEE" property. 1586 The "REPLY" method MAY also be used to respond to an unsuccessful 1587 "VTODO" calendar component "REQUEST" method. Depending on the 1588 "REQUEST-STATUS" value, no scheduling action MAY have been performed. 1590 The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" 1591 method from a "Calendar User" not in the original "REQUEST". For 1592 example, a "REPLY" method MAY be received from a "delegatee" of a 1593 "VTODO" calendar component. In addition, the "REPLY" method MAY be 1594 received from an unknown "Calendar User"; forwarded the "REQUEST" 1595 from an original "Attendee" assigned the "VTODO" calendar component. 1596 This uninvited "Attendee" MAY be accepted, or the "Organizer" MAY 1597 cancel the "VTODO" calendar component for the uninvited "Attendee" by 1598 sending them a "CANCEL" method. 1600 This method type is an iCalendar object that conforms to the 1601 following property constraints: 1603 (DESCRIPTION "VTODO - Reply" COMPONENT "VTODO" METHOD "REPLY" 1605 MUST COMPONENT = CALPROPS ( 1606 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REPLY"}) 1607 MUST COMPONENT = VTODO( 1608 MUST PROPERTY = ATTENDEE{MUST be address of ATTENDEE 1609 replying}, DTSTAMP, SEQUENCE{IF NE 0}, UID{UID 1610 associated with original REQUEST} 1611 MAY PROPERTY = COMMENT{provides comment from ATTENDEE to 1612 "Organizer"}, EXDATE, EXRULE, RECURRENCE-ID, REQUEST- 1613 STATUS, PERCENT-COMPLETE, SEQUENCE{IF EQ 0}, SUMMARY 1614 {MAYBE NULL}, URL 1615 NOT PROPERTY = ATTACH, CATEGORIES, CLASS, CREATED, 1616 DESCRIPTION, DTSTART, DUE, GEO, LAST-MODIFIED, PRIORITY, 1617 RELATED-TO, RESOURCES, RDATE, RRULE, STATUS, SUMMARY, 1618 TRANSP, URL) 1619 MAY COMPONENT = X-TOKENS (ANY) 1620 NOT COMPONENT = VEVENT 1621 NOT COMPONENT = VJOURNAL 1622 NOT COMPONENT = VFREEBUSY 1623 NOT COMPONENT = VTIMEZONE 1624 NOT COMPONENT = VALARM 1625 ) 1627 Silverberg/Mansour/Dawson/Hopson 33 Expires MAY 1998 1628 3.3.4 CANCEL 1630 The "CANCEL" method in a "VTODO" calendar component is used to send a 1631 cancellation notice of an existing "VTODO" calendar request request 1632 to the "Attendees". The message is sent by the "Organizer" of a 1633 "VTODO" calendar component to the "Attendees" of the "VTODO" calendar 1634 component. For a recurring "VTODO" calendar component, either the 1635 whole "VTODO" calendar component or instances of a "VTODO" calendar 1636 component MAY be cancelled. To cancel the complete range of a 1637 recurring "VTODO" calendar component, the "UID" property value for 1638 the "VTODO" calendar component MUST be specified in the "CANCEL" 1639 method. In order to cancel an individual instance of a recurring 1640 "VTODO" calendar component, the "RECURRENCE-ID" property value for 1641 the "VTODO" calendar component MUST be specified in the "CANCEL" 1642 method. In order to cancel a sequence of instances of a recurring 1643 "VTODO" calendar component, either the "RECURRENCE-ID" property for 1644 the first instance in the sequence MUST be specified with the "RANGE" 1645 property parameter value of THISANDPRIOR or THISANDFUTURE; to 1646 indicate cancellation of the "VTODO" calendar component instances 1647 before and after the first instance, respectively. Lastly, individual 1648 recurrence instances MAY be cancelled by specifying multiple 1649 "RECURRENCE-ID" properties corresponding to the instances to be 1650 cancelled. 1652 This method type is an iCalendar object that conforms to the 1653 following property constraints: 1655 (DESCRIPTION "VTODO - Cancel" COMPONENT "VTODO" METHOD "CANCEL" 1657 MUST COMPONENT = CALPROPS ( 1658 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"CANCEL"}) 1659 MUST COMPONENT = VTODO( 1660 MUST PROPERTY = DTSTAMP, SEQUENCE{IF NE 0}, UID{UID 1661 associated with original REQUEST} 1662 MAY PROPERTY = COMMENT{provides comment from "Organizer" to 1663 ATTENDEE}, EXDATE, EXRULE, RECURRENCE-ID, SEQUENCE{IF EQ 1664 0}, STATUS{CANCELLED} 1665 NOT PROPERTY = ATTACH, ATTENDEE, CATEGORIES, CLASS, CREATED, 1666 DESCRIPTION, DTSTART, DUE, GEO, LAST-MODIFIED, PRIORITY, 1667 RDATE, RELATED-TO, RESOURCES, REQUEST-STATUS, RRULE, 1668 SUMMARY, TRANSP, URL) 1669 MAY COMPONENT = X-TOKENS (ANY) 1670 NOT COMPONENT = VEVENT 1671 NOT COMPONENT = VJOURNAL 1672 NOT COMPONENT = VFREEBUSY 1673 NOT COMPONENT = VTIMEZONE 1674 NOT COMPONENT = VALARM 1675 ) 1677 Silverberg/Mansour/Dawson/Hopson 34 Expires MAY 1998 1678 3.3.5 REFRESH 1680 The "REFRESH" method in a "VTODO" calendar component is used by 1681 "Attendees" of an existing "VTODO" calendar component to request an 1682 updated description from the "Organizer" of the "VTODO" calendar 1683 component. The "Organizer" of the "VTODO" calendar component MAY also 1684 use this method to request an updated status from the "Attendees". 1685 The "REFRESH" method MUST specify the "UID" property corresponding to 1686 the "VTODO" calendar component needing update. 1688 A refresh of a recurrence instance of a "VTODO" calendar component 1689 MAY be requested by specifying the "RECURRENCE-ID" property 1690 corresponding to the associated "VTODO" calendar component. The 1691 "Organizer" MUST respond with the latest description and rendition of 1692 the "VTODO" calendar component. This method is intended to facilitate 1693 machine processing of requests for updates to a "VTODO" calendar 1694 component. 1696 This method type is an iCalendar object that conforms to the 1697 following property constraints: 1699 (DESCRIPTION "VTODO - Refresh" COMPONENT "VTODO" METHOD "REFRESH" 1701 MUST COMPONENT = CALPROPS ( 1702 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REFRESH"}) 1703 MUST COMPONENT = VTODO( 1704 MUST PROPERTY = ATTENDEE{address of requestor}, DTSTAMP, 1705 SEQUENCE{IF NE 0}, UID{UID associated with original 1706 REQUEST} MAY PROPERTY = COMMENT{provides comment from 1707 ATTENDEE to "Organizer"}, RECURRENCE-ID, SEQUENCE{IF EQ 1708 0} 1709 NOT PROPERTY = ATTACH, CATEGORIES, CLASS, CREATED, 1710 DESCRIPTION, DTSTART, DUE, EXDATE, EXRULE, GEO, LAST- 1711 MODIFIED, PRIORITY, RDATE,RELATED-TO, RESOURCES, 1712 REQUEST-STATUS, RRULE,SUMMARY, STATUS, TRANSP, URL) 1713 MAY COMPONENT = X-TOKENS (ANY) 1714 NOT COMPONENT = VEVENT 1715 NOT COMPONENT = VJOURNAL 1716 NOT COMPONENT = VFREEBUSY 1717 NOT COMPONENT = VTIMEZONE 1718 NOT COMPONENT = VALARM 1719 ) 1721 3.3.6 COUNTER 1723 The "COUNTER" method in a "VTODO" calendar component is used by an 1724 "Attendee" of an existing "VTODO" calendar component to submit to the 1725 "Organizer" a counter proposal for the "VTODO" calendar component. 1726 The "Attendee" MUST send the message to the "Organizer" of the 1727 "VTODO" calendar component. 1729 Silverberg/Mansour/Dawson/Hopson 35 Expires MAY 1998 1730 The counter proposal is an iCalendar object consisting of a "VTODO" 1731 calendar component describing the complete description of the 1732 alternate "VTODO" calendar component. 1734 The "Organizer" rejects the counter proposal by sending the 1735 "Attendee" a "DECLINE-COUNTER" method. The "Organizer" accepts the 1736 counter proposal by sending all of the "Attendees" of the "VTODO" 1737 calendar component a "REQUEST" method rescheduling the "VTODO" 1738 calendar component. In the later case, the "Organizer" SHOULD reset 1739 the individual "RSVP" property parameter values to TRUE on each 1740 "ATTENDEE" property; in order to force a response by the "Attendees". 1742 This method type is an iCalendar object that conforms to the 1743 following property constraints: 1745 (DESCRIPTION "VTODO- Request" COMPONENT "VTODO" METHOD "REQUEST" 1747 MUST COMPONENT = CALPROPS ( 1748 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REQUEST"}) 1749 MUST COMPONENT = VTODO( 1750 MUST PROPERTY = ATTENDEE{For Owner and Orginator if different 1751 and Attendees}, DESCRIPTION{MAYBE NULL}, DTSTAMP, 1752 DTSTART, PRIORITY, SEQUENCE{IF NE 0}, UID 1753 MAY PROPERTY = ATTACH, CATEGORIES, CLASS, COMMENT,CREATED, 1754 DUE, EXDATE, EXRULE, GEO, LAST-MODIFIED, 1755 LOCATION,RELATED-TO, RDATE, RECURRENCE-ID, RESOURCES, 1756 RRULE, SEQUENCE{IF EQ 0}, STATUS{TENTATIVE/CONFIRMED 1757 /CANCELLED}, SUMMARY{MAYBE NULL}, URL 1758 NOT PROPERTY = REQUEST-STATUS) 1759 MAY COMPONENT = VTIMEZONE ( 1760 MUST PROPERTY = DTSTART, TZOFFSET 1761 MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME 1762 NOT PROPERTY = CREATED) 1763 MAY COMPONENT = VALARM ( 1764 MUST PROPERTY = CATEGORIES, DSTART, DURATION, REPEAT 1765 MAY PROPERTY = ATTACH, DESCRIPTION, SUMMARY 1766 NOT PROPERTY = COMMENT, CREATED, LAST-MODIFIED, RELATED-TO, URL) 1767 MAY COMPONENT = X-TOKENS (ANY) 1768 NOT COMPONENT = VEVENT 1769 NOT COMPONENT = VJOURNAL 1770 NOT COMPONENT = VFREEBUSY 1771 ) 1773 3.3.7 DECLINECOUNTER 1775 The "DECLINE-COUNTER" method in a "VTODO" calendar component is used 1776 by an "Organizer" of "VTODO" calendar component to reject a counter 1777 proposal offered by one of the "Attendees". The "Organizer" MUST send 1778 the message to the "Attendee" that sent the "COUNTER" method to the 1779 "Organizer". 1781 Silverberg/Mansour/Dawson/Hopson 36 Expires MAY 1998 1782 The counter proposal is an iCalendar object consisting of a "VTODO" 1783 calendar component describing the complete description of the 1784 alternate "VTODO" calendar component. 1786 The "Organizer" rejects the counter proposal by sending the 1787 "Attendee" a "DECLINE-COUNTER" method. The "Organizer" accepts the 1788 counter proposal by sending all of the "Attendees" of the "VTODO" 1789 calendar component a "REQUEST" method rescheduling the "VTODO" 1790 calendar component. Since this is a rescheduled "VTODO", the 1791 "SEQUENCE" property value will be incremented. In the later case, the 1792 "Organizer" SHOULD reset the individual "RSVP" property parameter 1793 values to TRUE on all of the "ATTENDEE" properties in order to force 1794 a response by the "Attendees". 1796 This method type is an iCalendar object that conforms to the 1797 following property constraints: 1799 (DESCRIPTION "VTODO - Cancel" COMPONENT "VTODO" METHOD 1800 "DECLINECOUNTER" 1802 MUST COMPONENT = CALPROPS ( 1803 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD 1804 {"DECLINECOUNTER"}) 1805 MUST COMPONENT = VTODO( 1806 MUST PROPERTY = DTSTAMP, SEQUENCE{IF NE 0}, UID{same UID 1807 specified In Original REQUEST and subsequent COUNTER} 1808 MAY PROPERTY = COMMENT{provides comment from "Organizer" to 1809 ATTENDEE}, RECURRENCE-ID, REQUEST-STATUS, SEQUENCE{IF EQ 1810 0} 1811 NOT PROPERTY = ATTACH, ATTENDEE, CATEGORIES, CLASS, CREATED, 1812 DESCRIPTION, DTSTART, DUE, EXDATE, EXRULE, GEO, LAST- 1813 MODIFIED, PRIORITY, RDATE, RELATED-TO, RESOURCES, RRULE, 1814 STATUS, SUMMARY, TRANSP, URL) 1815 MAY COMPONENT = X-TOKENS (ANY) 1816 NOT COMPONENT = VEVENT 1817 NOT COMPONENT = VJOURNAL 1818 NOT COMPONENT = VFREEBUSY 1819 NOT COMPONENT = VTIMEZONE 1820 NOT COMPONENT = VALARM 1821 ) 1823 3.4 Methods For VJOURNAL Component 1825 This section defines the property set for the methods that are 1826 applicable to the "VJOURNAL" calendar component. Each of the methods 1827 is defined using a grammar that clarifies the property constraints 1828 that define the particular method. 1830 The following summarizes the methods that are defined for the 1831 "VJOURNAL" calendar component. 1833 +================+==================================================+ 1834 | Method | Description | 1836 Silverberg/Mansour/Dawson/Hopson 37 Expires MAY 1998 1837 |================+==================================================| 1838 | PUBLISH | Post a journal entry. Used primarily as a method | 1839 | | of advertising the existence of a journal entry | 1840 | CANCEL | Cancel an existing journal entry request. | 1841 | REFRESH | A request sent to the journal "Organizer" for | 1842 | | the latest version of the journal entry to be | 1843 | | resent the requester. | 1844 +================+==================================================+ 1846 3.4.1 PUBLISH 1848 The "PUBLISH" method in a "VJOURNAL" calendar component has no reply 1849 response associated with it. Instead, it is simply a posting of an 1850 iCalendar object that MAY be added to a calendar by a "Calendar User" 1851 agent. It requires and accepts no responses to the "Organizer". The 1852 expected usage is for encapsulating an arbitrary journal entry as an 1853 iCalendar object. The "Organizer" MAY subsequently update (with 1854 another "PUBLISH" method) or cancel (with a "CANCEL" method) a 1855 previously published journal entry. 1857 This method type is an iCalendar object that conforms to the 1858 following property constraints: 1860 (DESCRIPTION "Journal - Publish" COMPONENT "VJOURNAL" METHOD 1861 "PUBLISH 1863 MUST COMPONENT = CALPROPS ( 1864 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"PUBLISH"}) 1865 MUST COMPONENT = VJOURNAL ( 1866 MUST PROPERTY = DESCRIPTION{MAYBE NULL}, DTSTAMP, 1867 DTSTART{VALUE=DATE}, SEQUENCE{IF NE 0}, UID 1868 MAY PROPERTY = ATTACH, ATTENDEE{only ROLE=ORGANIZER and 1869 OWNER if different}, CATEGORIES, CLASS, COMMENT, 1870 CREATED, EXDATE, EXRULE, LAST-MODIFIED, RELATED-TO, 1871 RDATE, RECURRENCE-ID, RRULE, SEQUENCE{IF EQ 0}, 1872 SUMMARY{MAYBE NULL}, URL 1873 NOT PROPERTY = REQUEST-STATUS) 1874 MAY COMPONENT = VTIMEZONE ( 1875 MUST PROPERTY = DTSTART, TZOFFSET 1876 MAY PROPERTY = COMMENT, DAYLIGHT, (RDATE / RRULE), TZNAME 1877 NOT PROPERTY = CREATED) 1878 MAY COMPONENT = X-TOKENS (ANY) 1879 NOT COMPONENT = VEVENT 1880 NOT COMPONENT = VTODO 1881 NOT COMPONENT = VALARM 1882 NOT COMPONENT = VFREEBUSY 1883 ) 1885 Silverberg/Mansour/Dawson/Hopson 38 Expires MAY 1998 1886 3.4.2 CANCEL 1888 The "CANCEL" method in a "VJOURNAL" calendar component is used to 1889 send a cancellation notice of an existing journal entry request to 1890 the "Attendees". The message is sent by the "Organizer" of a journal 1891 entry to the "Attendees" of the journal entry. For a recurring 1892 journal entry, either the whole journal entry or instances of a 1893 journal entry MAY be cancelled. To cancel the complete range of a 1894 recurring journal entry, the "UID" property value for the journal 1895 entry MUST be specified in the "CANCEL" method. In order to cancel an 1896 individual instance of the journal entry, the "RECURRENCE-ID" 1897 property value for the journal entry MUST be specified in the 1898 "CANCEL" method. In order to cancel a sequence of instances in a 1899 recurring journal entry, the "RECURRENCE-ID" property for the first 1900 journal entry instance in the sequence MUST be specified with the 1901 "RANGE" property parameter value of THISANDPRIOR or THISANDFUTURE; to 1902 indicate cancellation of the journal entry instances before and after 1903 the first journal entry instance, respectively. Lastly, individual 1904 recurrence instances MAY be cancelled by specifying multiple 1905 "RECURRENCE-ID" properties corresponding to the instances to be 1906 cancelled. 1908 This method type is an iCalendar object that conforms to the 1909 following property constraints: 1911 (DESCRIPTION "Journal - Cancel" COMPONENT "VJOURNAL" METHOD 1912 "CANCEL" 1914 MUST COMPONENT = CALPROPS ( 1915 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"CANCEL"}) 1916 MUST COMPONENT = VJOURNAL ( 1917 MUST PROPERTY = DTSTAMP, SEQUENCE{IF NE 0}, UID{UID 1918 associated with original REQUEST} 1919 MAY PROPERTY = COMMENT{provides comment from "Organizer" to 1920 ATTENDEE}, EXDATE, EXRULE, RECURRENCE-ID, SEQUENCE{IF EQ 1921 0}, STATUS{CANCELLED} 1922 NOT PROPERTY = ATTACH, ATTENDEE, CATEGORIES, CLASS, CREATED, 1923 DESCRIPTION, DTSTART, LAST-MODIFIED, RDATE, RELATED-TO, 1924 REQUEST-STATUS, RRULE, SUMMARY, URL) 1925 MAY COMPONENT = X-TOKENS (ANY) 1926 NOT COMPONENT = VEVENT 1927 NOT COMPONENT = VTODO 1928 NOT COMPONENT = VFREEBUSY 1929 NOT COMPONENT = VTIMEZONE 1930 NOT COMPONENT = VALARM 1931 ) 1933 3.4.3 REFRESH 1935 The "REFRESH" method in a "VJOURNAL" calendar component is used by 1936 "Attendees" of an existing journal entry to request an updated 1937 description from the journal entry "Organizer". The "REFRESH" method 1939 Silverberg/Mansour/Dawson/Hopson 39 Expires MAY 1998 1940 MUST specify the "UID" property corresponding to the journal entry 1941 needing update. A recurrence instance of a journal entry MAY be 1942 requested by specifying the"RECURRENCE-ID" property corresponding to 1943 the associated journal entry. The "Organizer" MUST respond with the 1944 latest description and version of the journal entry. This method is 1945 intended to facilitate machine processing of the "REFRESH" response. 1947 This method type is an iCalendar object that conforms to the 1948 following property constraints: 1950 (DESCRIPTION "Journal - Refresh" COMPONENT "VJOURNAL" METHOD 1951 "REFRESH" 1953 MUST COMPONENT = CALPROPS ( 1954 MUST PROPERTY = PRODID, VERSION{"2.0"}, METHOD{"REFRESH"}) 1955 MUST COMPONENT = VJOURNAL ( 1956 MUST PROPERTY = ATTENDEE{address of requestor}, DTSTAMP, 1957 SEQUENCE{IF NE 0}, UID{UID associated with original 1958 REQUEST} 1959 MAY PROPERTY = COMMENT{provides comment from ATTENDEE to 1960 "Organizer"}, RECURRENCE-ID, SEQUENCE{IF EQ 0} 1961 NOT PROPERTY = ATTACH, CATEGORIES, CLASS, CREATED, 1962 DESCRIPTION, DTSTART, EXDATE, EXRULE, LAST-MODIFIED, 1963 PRIORITY, RDATE, RELATED-TO, REQUEST-STATUS, RRULE, 1964 SUMMARY, URL) 1965 MAY COMPONENT = X-TOKENS (ANY) 1966 NOT COMPONENT = VEVENT 1967 NOT COMPONENT = VTODO 1968 NOT COMPONENT = VFREEBUSY 1969 NOT COMPONENT = VTIMEZONE 1970 NOT COMPONENT = VALARM 1971 ) 1973 3.5 Status Replies 1975 The "REQUEST-STATUS" property MAY include the following values: 1977 |==============+============================+=========================| 1978 | Short Return | Longer Return Status | Offending Data | 1979 | Status Code | Description | | 1980 |==============+============================+=========================| 1981 | 2.0 | Success. | None. | 1982 |==============+============================+=========================| 1983 | 2.1 | Success but fallback taken | Property name and value | 1984 | | on one or more property | MAY be specified. | 1985 | | values. | | 1986 |==============+============================+=========================| 1987 | 2.2 | Success, invalid property | Property name MAY be | 1988 | | ignored. | specified. | 1989 |==============+============================+=========================| 1990 | 2.3 | Success, invalid property | Property parameter name | 1991 | | parameter ignored. | and value MAY be | 1993 Silverberg/Mansour/Dawson/Hopson 40 Expires MAY 1998 1994 | | | specified. | 1995 |==============+============================+=========================| 1996 | 2.4 | Success, unknown non- | Non-standard property | 1997 | | standard property ignored. | name MAY be specified. | 1998 |==============+============================+=========================| 1999 | 2.5 | Success, unknown non | Property and non- | 2000 | | standard property value | standard value MAY be | 2001 | | ignored. | specified. | 2002 |==============+============================+=========================| 2003 | 2.6 | Success, invalid calendar | Calendar component | 2004 | | component ignored. | sentinel (e.g., "BEGIN: | 2005 | | | ALARM") MAY be | 2006 | | | specified. | 2007 |==============+============================+=========================| 2008 | 2.7 | Success, request forwarded | Original and forwarded | 2009 | | to Calendar User. | caluser addresses MAY | 2010 | | | be specified. | 2011 |==============+============================+=========================| 2012 | 2.8 | Success, repeating event | RRULE or RDATE property | 2013 | | ignored. Scheduled as a | name and value MAY be | 2014 | | single event. | specified. | 2015 |==============+============================+=========================| 2016 | 2.9 | Success, truncated end date| DTEND property value | 2017 | | time to date boundary. | MAY be specified. | 2018 |==============+============================+=========================| 2019 | 2.10 | Success, repeating VTODO | RRULE or RDATE property | 2020 | | ignored. Scheduled as a | name and value MAY be | 2021 | | single VTODO. | specified. | 2022 |==============+============================+=========================| 2023 | 3.0 | Invalid property name. | Property name MAY be | 2024 | | | specified. | 2025 |==============+============================+=========================| 2026 | 3.1 | Invalid property value. | Property name and value | 2027 | | | MAY be specified. | 2028 |==============+============================+=========================| 2029 | 3.2 | Invalid property parameter.| Property parameter name | 2030 | | | and value MAY be | 2031 | | | specified. | 2032 |==============+============================+=========================| 2033 | 3.3 | Invalid property parameter | Property parameter name | 2034 | | value. | and value MAY be | 2035 | | | specified. | 2036 |==============+============================+=========================| 2037 | 3.4 | Invalid calendar component | Calendar component | 2038 | | sequence. | sentinel MAY be | 2039 | | | specified (e.g., BEGIN: | 2040 | | | VTIMEZONE). | 2041 |==============+============================+=========================| 2042 | 3.5 | Invalid date or time. | Date/time value(s) MAY | 2043 | | | be specified. | 2044 |==============+============================+=========================| 2045 | 3.6 | Invalid rule. | Rule value MAY be | 2046 | | | specified. | 2047 |==============+============================+=========================| 2049 Silverberg/Mansour/Dawson/Hopson 41 Expires MAY 1998 2050 | 3.7 | Invalid Calendar User. | Attendee property value | 2051 | | |MAY be specified. | 2052 |==============+============================+=========================| 2053 | 3.8 | No authority. | PROFILE and ATTENDEE | 2054 | | | property values MAY be | 2055 | | | specified. | 2056 |==============+============================+=========================| 2057 | 3.9 | Unsupported version. | VERSION property name | 2058 | | | and value MAY be | 2059 | | | specified. | 2060 |==============+============================+=========================| 2061 | 3.10 | Request entity too large. | None. | 2062 |==============+============================+=========================| 2063 | 4.0 | Event conflict. Date/time | DTSTART and DTEND | 2064 | | is busy. | property name and values| 2065 | | | MAY be specified. | 2066 |==============+============================+=========================| 2067 | 5.0 | Request not supported. | Method property value | 2068 | | | MAY be specified. | 2069 |==============+============================+=========================| 2070 | 5.1 | Service unavailable. | ATTENDEE property value | 2071 | | | MAY be specified. | 2072 |==============+============================+=========================| 2073 | 5.2 | Invalid calendar service. | ATTENDEE property value | 2074 | | | MAY be specified. | 2075 |==============+============================+=========================| 2076 | 5.3 | No scheduling support for | ATTENDEE property value | 2077 | | user. | MAY be specified. | 2078 |==============+============================+=========================| 2080 3.6 Implementation Considerations 2082 3.6.1 Working With Recurrence Instances 2084 iCalendar includes a recurrence grammar to represent recurring 2085 events. The benefit of such a grammar is the ability to represent a 2086 number of events in a single object. However, while this simplifies 2087 creation of a recurring event, meeting instances MAY still need to be 2088 referenced. For instance, an "Attendee" MAY decline the third 2089 instance of a recurring Friday event. Similarly, the "Organizer" MAY 2090 change the time or location to a single instance of the recurring 2091 event. 2093 Since implementations MAY elect to store recurring events as either a 2094 single event object or a collection of discreet, related event 2095 objects, the protocol is designed so that each recurring instance MAY 2096 be both referenced and versioned. Hence, implementations that choose 2097 to maintain per-instance properties (such as "ATTENDEE" property 2098 "STATUS" parameter) MAY do so. However, the protocol does not require 2099 per-instance recognition unless the instance itself MUST be 2100 renegotiated. 2102 Silverberg/Mansour/Dawson/Hopson 42 Expires MAY 1998 2103 The scenarios for recurrence instance referencing are listed below. 2104 For purposes of simplification a change to an event refers to a 2105 "trigger property." That is, a property that has a substantive 2106 affect on the meeting itself such as start time, location, due date 2107 (for "VTODO" calendar component components) and possibly description. 2109 . "Organizer" initiated actions: 2111 . "Organizer" deletes or changes a single instance of a recurring 2112 event 2114 . "Organizer" makes changes that affect all future instances 2116 . "Organizer" makes changes that affect all previous instances 2118 . "Organizer" deletes or modifies a previously changed instance 2120 . Attendee initiated actions: 2122 . Attendee changes status for a particular recurrence instance 2124 . Attendee sends Event-Counter for a particular recurrence 2125 instance 2127 An instance of a recurring event is assigned a unique identification, 2128 "RECURRENCE-ID" property, when that instance MUST be renegotiated. 2129 Negotiation is necessary when the start time, end time, due date or 2130 location are modified. If the "Organizer" wishes to identify a 2131 specific recurrence instance it is done using the "RECURRENCE-ID" 2132 property. The property value is equal to the date/time of the 2133 instance. If the "Organizer" wishes to change the"DTSTART", the 2134 original "DTSTART" value is used for"RECURRENCE-ID" property and the 2135 new "DTSTART" and "DTEND" values reflect the change. If the 2136 "Organizer" wishes to add a new instance to the recurring event then 2137 a "REQUEST" is issued with an "RDATE" property equal to the new 2138 instance date. It is recommended that the "Organizer" include the 2139 "RECURRENCE-ID" property[SS1]. Since the creation of a new event 2140 instance requires negotiation, the sequence number is also 2141 incremented. 2143 3.6.2 Attendee Property Considerations 2145 The "ATTENDEE" property for the "Organizer" is required on published 2146 events, to-dos, and journal entries for two reasons. First, a 2147 published only the "Organizer" is allowed to update an event, to-do, 2148 or journal entry component. The "Organizer" "ATTENDEE" property MUST 2149 be present in the event, to-do, or journal entry component so that 2150 the "CUA" has a basis for authorizing an update. Second, it is 2151 prudent to provide a point of contact for anyone who receives a 2152 published component in case of problems. 2154 There are valid RFC 822 addresses that represent groups. Sending 2155 email to such an address results in mail being sent to multiple 2157 Silverberg/Mansour/Dawson/Hopson 43 Expires MAY 1998 2158 recipients. Such an address MAY be used as the value of an "ATTENDEE" 2159 property. Thus, it is possible that the recipient of a "REQUEST" does 2160 not appear explicitly in the list list. 2162 It is recommended that the general approach to finding a "Calendar 2163 User" in an attendee list be as follows: 2165 1. 2166 Search for the "Calendar User" in the attendee list where 2167 "TYPE=INDIVIDUAL" 2169 2. 2170 Failing (1) look for attendees where "TYPE=GROUP" or 2171 'TYPE=UNKNOWN". The "CUA" MUST then determine if the "CU" is a 2172 member of one of these groups. If so, the "REPLY" method sent to 2173 the "Organizer" MUST contain a new "ATTENDEE" property in which 2174 the "TYPE" property parameter is set to INDIVIDUAL and the 2175 "GROUP" property parameter is set to the name of the group. 2177 3. 2178 Failing (2) the "CUA" MAY ignore or accept the request as the 2179 "Calendar User" wishes. 2181 3.6.3 When To Refresh An Event 2183 An "VEVENT" or "VTODO" calendar component SHOULD be resent to all 2184 "Attendees" whenever the "SEQUENCE" property is incremented or any 2185 other substantive change is made. 2187 3.6.4 Timezones 2189 If a recurring event has any instance where "DTSTART" and "DTEND" 2190 fall on different sides of a time zone shift, the "VTIMEZONE" 2191 components are required. 2193 The threat of duplicate time zone definitions exists. SHOULD an 2194 iCalendar object contain multiple conflicting time zone components, 2195 the one with the latest "DTSTART" property supersedes the others. 2197 3.6.5 Alarms 2199 It is recommended that application software ask the user whether or 2200 not they want alarms included when they read the event. 2202 3.6.6 SUMMARY Property 2204 The minimum support for the "SUMMARY" property in a recipient MUST be 2205 for a 255 byte value. Implementations MAY truncate longer length 2206 values. 2208 Silverberg/Mansour/Dawson/Hopson 44 Expires MAY 1998 2209 3.6.7 X-Tokens 2211 To make iCalendar objects extensible, new property types MAY be 2212 inserted into components. These properties are called X-Tokens as 2213 they are prefixed with "X-". A client is not required to make sense 2214 of X-Tokens. Clients are not required to save X-Tokens or use them in 2215 event replies. 2217 4 Examples 2219 4.1 Published Event Examples 2221 In the calendaring and scheduling context, publication refers to the 2222 one way transfer of event information. Consumers of published events 2223 simply incorporate the event into a calendar. No reply is expected. 2224 Individual "A" publishes an event. Individual "B" reads the event and 2225 incorporates it into their calendar. Events MAY be published in 2226 several ways including: embedding the event as an object in a web 2227 page, e-mailing the event to a distribution list, and posting the 2228 event to a newsgroup. 2230 The table below illustrates the sequence of events between the 2231 publisher and the consumers of a published event. 2233 +-------------------------------------------------------------------+ 2234 | Action | "Organizer" | 2235 +---------------------------------+---------------------------------+ 2236 | Publish an event | "A" sends or posts a PUBLISH | 2237 | | message | 2238 +---------------------------------+---------------------------------+ 2239 | "B" reads a published event | | 2240 +---------------------------------+---------------------------------+ 2241 | Publish an updated event | "A" sends or posts a PUBLISH | 2242 | | message | 2243 +---------------------------------+---------------------------------+ 2244 | "B" reads the updated event | | 2245 +---------------------------------+---------------------------------+ 2246 | Cancel a published event | "A" sends or posts a CANCEL | 2247 | | message | 2248 +---------------------------------+---------------------------------+ 2249 | "B" reads the canceled event | | 2250 | publication | | 2251 +---------------------------------+---------------------------------+ 2253 4.1.1 A Minimal Published Event 2255 The iCalendar object below describes a single event that begins on 2256 July 1, 1997 at 20:00 UTC. This event contains the minimum set of 2257 properties for a "PUBLISH" for a "VEVENT" calendar component. 2259 Silverberg/Mansour/Dawson/Hopson 45 Expires MAY 1998 2260 BEGIN:VCALENDAR 2261 METHOD:PUBLISH 2262 PRODID:-//ACME/DesktopCalendar//EN 2263 VERSION:2.0 2264 BEGIN:VEVENT 2265 ATTENDEE;ROLE=OWNER:mailto:a@host.com 2266 DTSTART:19970701T200000Z 2267 DTSTAMP:19970611T190000Z 2268 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 2269 UID:0981234-1234234-23@host.com 2270 END:VEVENT 2271 END:VCALENDAR 2273 4.1.2 Changing A Published Event 2275 The iCalendar object below describes an update to the event described 2276 in 4.1.1, the time has been changed, an end time has been added, and 2277 the sequence number has been adjusted. 2279 BEGIN:VCALENDAR 2280 METHOD:PUBLISH 2281 VERSION:2.0 2282 PRODID:-//ACME/DesktopCalendar//EN 2283 BEGIN:VEVENT 2284 ATTENDEE;ROLE=OWNER:mailto:A@example.com 2285 DTSTAMP:19970612T190000Z 2286 DTSTART:19970701T210000Z 2287 DTEND:19970701T230000Z 2288 SEQUENCE:2 2289 UID:0981234-1234234-23@host.com 2290 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 2291 END:VEVENT 2292 END:VCALENDAR 2294 The "UID" property is used by the client to identify the event. The 2295 "SEQUENCE" property indicates that this is the second change to the 2296 event. Events with sequence numbers 0 and 1 are superseded by this 2297 event. 2299 The "SEQUENCE" property provides a reliable way to distinguish 2300 different versions of the same event. Each time an event is 2301 published, its sequence number is incremented. If a client receives 2302 an event with a sequence number 5 and finds it has the same event 2303 with sequence number 2, the event SHOULD be updated. However, if the 2304 client received an event with sequence number 2 and finds it already 2305 has sequence number 5 of the same event, the event SHOULD NOT be 2306 updated. 2308 Silverberg/Mansour/Dawson/Hopson 46 Expires MAY 1998 2309 4.1.3 Canceling A Published Event 2311 The iCalendar object below cancels the event described in 4.1.1. This 2312 cancels the event with "SEQUENCE" property of 0, 1, and 2. 2314 BEGIN:VCALENDAR 2315 METHOD:CANCEL 2316 VERSION:2.0 2317 PRODID:-//ACME/DesktopCalendar//EN 2318 BEGIN:VEVENT 2319 ATTENDEE;ROLE=OWNER:mailto:A@example.com 2320 COMMENT:DUKES forfeit the game 2321 SEQUENCE:2 2322 UID:0981234-1234234-23@host.com 2323 DTSTAMP:19970613T190000Z 2324 STATUS:CANCELLED 2325 END:VEVENT 2326 END:VCALENDAR 2328 4.1.4 A Rich Published Event 2330 This example describes the same event as in 4.1.1, but in much 2331 greater detail. 2333 BEGIN:VCALENDAR 2335 PRODID:-//ACME/DesktopCalendar//EN 2336 METHOD:PUBLISH 2337 SCALE:GREGORIAN 2338 SOURCE:http://www.midwaystadium.com/stadium-cal/1997-events.or4 2339 NAME:1997 GAME SCHEDULE 2340 VERSION:2.0 2342 BEGIN:VTIMEZONE 2343 DAYLIGHT:TRUE 2344 DTSTART:19970406T070000-0600 2345 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 2346 TZNAME:CDT 2347 TZOFFSET:-0500 2348 END:VTIMEZONE 2350 BEGIN:VTIMEZONE 2351 DAYLIGHT:FALSE 2352 DTSTART:19971026T0200-0500 2353 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 2354 TZNAME:CST 2355 TZOFFSET:-0600 2356 END:VTIMEZONE 2358 BEGIN:VEVENT 2359 ATTENDEE;ROLE=OWNER:mailto:A@example.com 2361 Silverberg/Mansour/Dawson/Hopson 47 Expires MAY 1998 2362 ATTACH:http://www.midwaystadium.com 2363 CATEGORIES:SPORTS EVENT;ENTERTAINMENT 2364 CLASS:PRIVATE 2365 CREATED:19970415T194319Z 2366 DESCRIPTION:MIDWAY STADIUM\n 2367 Big time game. MUST see.\n 2368 Expected duration:2 hours\n 2369 DTEND:19970701T180000 2370 DTSTART:19970702T160000 2371 DTSTAMP:19970614T190000Z 2372 STATUS:CONFIRMED 2373 LAST-MODIFIED:19970416T162421Z 2374 LOCATION;VALUE=URL:http://www.midwaystadium.com/ 2375 PRIORITY:2 2376 RESOURCES:SCOREBOARD 2377 SEQUENCE:3 2378 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 2379 UID:0981234-1234234-23@host.com 2380 RELATED-TO:0981234-1234234-14@host.com 2382 BEGIN:VALARM 2383 DTSTART:19970701T190000Z 2384 REPEAT:2 2385 DURATION:PT2H 2386 CATEGORIES:DISPLAY,AUDIO 2387 DESCRIPTION:It's almost game time 2388 END:VALARM 2390 BEGIN:VALARM 2391 DTSTART:19970701T153000 2392 CATEGORIES:DISPLAY,AUDIO 2393 DESCRIPTION:You SHOULD leave now. Game starts in 30 min! 2394 END:VALARM 2396 END:VEVENT 2397 END:VCALENDAR 2399 The "CLASS" property is specified, though it is not really needed 2400 here. Since this is a published event, a program that displays it 2401 need not apply any content filtering based on the "CLASS" attribute. 2402 If this event is copied into a user's calendar, the "CLASS" would be 2403 included as part of the copy. The handling of the "CLASS" tag at 2404 that point is implementation specific. 2406 The "RELATED-TO" field contains the "UID" property of a related 2407 calendar event. The handling of this property is application 2408 dependent. 2410 The "SEQUENCE" property 3 indicates that this event supersedes 2411 versions 0, 1, and 2. 2413 Silverberg/Mansour/Dawson/Hopson 48 Expires MAY 1998 2414 4.1.5 Anniversaries or Events attached to entire days 2416 This example demonstrates the use of the "value" parameter to tie a 2417 VEVENT to day rather than a specific time. 2419 BEGIN:VCALENDAR 2420 PRODID:-//ACME/DesktopCalendar//EN 2421 METHOD:PUBLISH 2422 VERSION:2.0 2423 BEGIN:VEVENT 2424 DTSTAMP:19970614T190000Z 2425 UID:0981234-1234234-23@host.com 2426 DTSTART;VALUE=DATE:19970714 2427 RRULE:FREQ=YEARLY;INTERVAL=1 2428 SUMMARY: Bastille Day 2429 END:VEVENT 2430 END:VCALENDAR 2432 4.2 Group Event Examples 2434 Group events are distinguished from published events in that they 2435 have "Attendees" and that there is interaction between the 2436 "Attendees" with respect to the event. Individual "A" requests a 2437 meeting between individuals "A", "B", "C" and "D". Individual "B" 2438 confirms attendance to the meeting. Individual "C" declines 2439 attendance. Individual "D" tentatively confirms their attendance. 2440 This is sometimes referred to as "penciling-in" the event on a 2441 calendar. The following table illustrates the sequence of messages 2442 that would be exchanged between these individuals. The table below 2443 illustrates the message flow. 2445 +--------------------------------------------------------------------+ 2446 | Action | "Organizer" | Attendee | 2447 +--------------------------------------------------------------------+ 2448 | Initiate a meeting | "A" sends a REQUEST | | 2449 | request | message to "B", "C",| | 2450 | | and "D" | | 2451 +--------------------------------------------------------------------+ 2452 | Accept the meeting | | "B" sends a REPLY | 2453 | request | | message to "A" with its | 2454 | | | ATTENDEE STATUS para- | 2455 | | | set to "ACCEPTED" | 2456 +--------------------------------------------------------------------+ 2457 | Decline the meeting| | "C" sends a REPLY | 2458 | request | | message to "A" with its | 2459 | | | ATTENDEE STATUS para- | 2460 | | | set to "DECLINED" | 2461 +--------------------------------------------------------------------+ 2462 | Tentatively accept | | "D" sends a REPLY | 2463 | the meeting request| | message to "A" with its | 2464 | | | ATTENDEE STATUS para- | 2466 Silverberg/Mansour/Dawson/Hopson 49 Expires MAY 1998 2467 | | | set to "TENTATIVE" | 2468 +--------------------------------------------------------------------+ 2469 | Confirm meeting | "A" sends a REQUEST | | 2470 | status with | message to "B" and | | 2471 | attendees | "C" with updated | | 2472 | | information. | | 2473 +--------------------------------------------------------------------+ 2475 4.2.1 A Group Event Request 2477 A sample meeting request that "A" sends to "B", "C", and "D". 2479 BEGIN:VCALENDAR 2480 PRODID:-//ACME/DesktopCalendar//EN 2481 METHOD:REQUEST 2482 VERSION:2.0 2483 BEGIN:VEVENT 2484 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 2485 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 2486 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:B@example. 2487 com 2488 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:C@example. 2489 com 2490 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:D@example. 2491 com 2492 ATTENDEE;RSVP=FALSE;EXPECT=REQUIRE;TYPE=ROOM:CR_Big@example.com 2493 DTSTAMP:19970611T190000Z 2494 DTSTART:19970701T100000-0700 2495 DTEND:19970701T103000-0700 2496 SUMMARY:Phone Conference 2497 UID:www.acme.com-873970198738777@host.com 2498 SEQUENCE:0 2499 STATUS:CONFIRMED 2500 END:VEVENT 2501 END:VCALENDAR 2503 4.2.2 Reply To A Group Event Request 2505 Attendee "B" accepts the meeting. 2507 BEGIN:VCALENDAR 2508 PRODID:-//ACME/DesktopCalendar//EN 2509 METHOD:REPLY 2510 VERSION:2.0 2511 BEGIN:VEVENT 2512 ATTENDEE;STATUS=ACCEPTED:Mailto:B@example.com 2513 UID:www.acme.com-873970198738777@host.com 2514 SEQUENCE:0 2515 REQUEST-STATUS:2.0;Success 2516 DTSTAMP:19970612T190000Z 2518 Silverberg/Mansour/Dawson/Hopson 50 Expires MAY 1998 2519 END:VEVENT 2520 END:VCALENDAR 2522 "B" could have declined the meeting or indicated tentative acceptance 2523 by setting the ATTENDEE;"STATUS" parameter to DECLINED or TENTATIVE, 2524 respectively. 2526 4.2.3 Update An Event 2528 The event is moved to a different time. The combination of the "UID" 2529 property(which remains the same) and the SEQUENCE (bumped to 1) 2530 properties indicate the update. 2532 BEGIN:VCALENDAR 2533 PRODID:-//ACME/DesktopCalendar//EN 2534 METHOD:REQUEST 2535 VERSION:2.0 2536 BEGIN:VEVENT 2537 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 2538 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 2539 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:B@example. 2540 com 2541 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:C@example. 2542 com 2543 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:D@example. 2544 com 2545 ATTENDEE;RSVP=FALSE;EXPECT=REQUIRE;TYPE=ROOM:CR_Big@example.com 2546 DTSTART:19970701T110000-0700 2547 DTEND:19970701T113000-0700 2548 SUMMARY:Phone Conference 2549 UID:www.acme.com-873970198738777@host.com 2550 SEQUENCE:1 2551 DTSTAMP:19970613T190000Z 2552 STATUS:CONFIRMED 2553 END:VEVENT 2554 END:VCALENDAR 2556 4.2.4 Countering an Event Proposal 2558 Attendee A sends "REQUEST" to B and C. B makes a counter proposal to 2559 A to change the time and location. 2561 Attendee A sends "REQUEST": 2563 BEGIN:VCALENDAR 2564 PRODID:-//ACME/DesktopCalendar//EN 2565 METHOD:REQUEST 2566 VERSION:2.0 2567 BEGIN:VEVENT 2568 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 2570 Silverberg/Mansour/Dawson/Hopson 51 Expires MAY 1998 2571 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 2572 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:B@example. 2573 com 2574 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:C@example. 2575 com 2576 DTSTART:19970701T190000Z 2577 DTEND:19970701T200000Z 2578 SUMMARY:Discuss the Merits of the election results 2579 LOCATION:The Big Conference Room 2580 UID:www.acme.com-873970198738777@host.com 2581 SEQUENCE:0 2582 DTSTAMP:19970611T190000Z 2583 STATUS:CONFIRMED 2584 END:VEVENT 2585 END:VCALENDAR 2587 Attendee B sends "COUNTER" to A, requesting changes to time and 2588 place: 2590 BEGIN:VCALENDAR 2591 PRODID:-//ACME/DesktopCalendar//EN 2592 METHOD:COUNTER 2593 VERSION:2.0 2594 BEGIN:VEVENT 2595 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 2596 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 2597 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:B@example. 2598 com 2599 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:C@example. 2600 com 2601 DTSTART:19970701T160000Z 2602 DTEND:19970701T190000Z 2603 DTSTAMP:19970612T190000Z 2604 SUMMARY:Discuss the Merits of the election results 2605 LOCATION:The Small Conference Room 2606 COMMENT:This time works much better and I think the big conference 2607 room is too big 2608 UID:www.acme.com-873970198738777@host.com 2609 SEQUENCE:0 2610 DTSTAMP:19970611T190000Z 2611 END:VEVENT 2612 END:VCALENDAR 2614 Attendee A accepts the changes from B 2616 BEGIN:VCALENDAR 2617 PRODID:-//ACME/DesktopCalendar//EN 2618 METHOD:REQUEST 2619 VERSION:2.0 2620 BEGIN:VEVENT 2621 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 2622 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 2624 Silverberg/Mansour/Dawson/Hopson 52 Expires MAY 1998 2625 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:B@example. 2626 com 2627 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:C@example. 2628 com 2629 DTSTAMP:19970613T190000Z 2630 DTSTART:19970701T160000Z 2631 DTEND:19970701T190000Z 2632 SUMMARY:Discuss the Merits of the election results - changed to 2633 suite B's schedule 2634 LOCATION:The Small Conference Room 2635 UID:www.acme.com-873970198738777@host.com 2636 SEQUENCE:1 2637 STATUS:CONFIRMED 2638 END:VEVENT 2639 END:VCALENDAR 2641 A rejects B's counter proposal 2643 BEGIN:VCALENDAR 2644 PRODID:-//ACME/DesktopCalendar//EN 2645 METHOD:DECLINECOUNTER 2646 VERSION:2.0 2647 BEGIN:VEVENT 2648 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 2649 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 2650 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:B@example. 2651 com 2652 COMMENT:Sorry, I cannot change this meeting time 2653 UID:www.acme.com-873970198738777@host.com 2654 SEQUENCE:1 2655 DTSTAMP:19970614T190000Z 2656 END:VEVENT 2658 4.2.5 Delegate An Event 2660 When delegating an event request to another "Calendar User", the 2661 "delegator" MUST both update the "Organizer" with a "REPLY" and send 2662 a request to the "delegatee". There is currently no protocol 2663 limitation to delegation depth. It is possible for the original 2664 delegate to delegate the meeting to someone else, and so on. When a 2665 request is delegated from one "CUA" to another there are a number of 2666 responsibilities required of the "delegator". They MUST: 2668 . Send an REPLY to the "Organizer" with their attendee/status 2669 property parameter set to "Delegated" 2671 . Include the delegate as an additional attendee with the 2672 "Delegated-From" property parameter set to the delegator 2674 . Include the original UID of the REQUEST 2676 Silverberg/Mansour/Dawson/Hopson 53 Expires MAY 1998 2677 . The delegator MUST also send a copy of the original REQUEST to 2678 the delegate. The delegator modifies the request to include: 2680 . The ATTENDEE/STATUS property parameter for the delegator 2681 (sender in this case) is set to "DELEGATED" 2683 . ATTENDEE/DELEGATED-TO parameter is set to the address of the 2684 delegatee 2686 . An ATTENDEE property is added for delegatee 2688 As a rule, it is not required that the "delegatee" include the 2689 "delegator" in their "REPLY" method. However, it is strongly advised 2690 since this will inform the "delegator" whether their proxy plans to 2691 attend the meeting. If the "delegatee" declines the meeting, the 2692 "delegator" MAY elect to try and delegate the "REQUEST" to another 2693 "CUA". The process is the same. 2695 +---------------------------------------------------------------------+ 2696 | Action | "Organizer" | Attendee | 2697 +---------------------------------------------------------------------+ 2698 | Initiate a meeting | "A" sends a REQUEST | | 2699 | request | message to "B" and | | 2700 +---------------------------------------------------------------------+ 2701 | Delegate: | | "C" sends a REPLY to "A" | 2702 | "C" delegates to | | with the ATTENDEE.STATUS | 2703 | "E" | | parameter set to | 2704 | | | "DELEGATED" and with a | 2705 | | | new ATTENDEE property | 2706 | | | for "E". "E's" ATTENDEE | 2707 | | | DELEGATED-FROM property | 2708 | | | is set to "C". "C's" | 2709 | | | ATTENDEE.DELEGATED-TO | 2710 | | | property is set to "E". | 2711 | | | "C" sends REQUEST message| 2712 | | | to "E" with the original | 2713 | | | meeting request | 2714 | | | information. The | 2715 | | | ATTENDEE/STATUS property | 2716 | | | parameter for "C" is set | 2717 | | | to "DELEGATED" and the | 2718 | | | ATTENDEE/DELEGATED-TO | 2719 | | | parameter is set to | 2720 | | | the address of "E". An | 2721 | | | ATTENDEE property is | 2722 | | | added for "E" and the | 2723 | | | ATTENDEE/DELEGATED-FROM | 2724 | | | parameter is set to | 2725 | | | the address of "C". | 2726 +---------------------------------------------------------------------+ 2727 | Confirm meeting | | "E" sends REPLY message | 2728 | attendance | | to "A" and optionally "C"| 2729 | | | with its ATTENDEE/STATUS | 2730 | | | property parameter set | 2732 Silverberg/Mansour/Dawson/Hopson 54 Expires MAY 1998 2733 | | | to "ACCEPTED" | 2734 +---------------------------------------------------------------------+ 2735 | Optional: | "A" sends REQUEST | | 2736 | Redistribute | message to "B", "C" | | 2737 | meeting to | and "E". SEQUENCE | | 2738 | attendees | number is now 1. | | 2739 +---------------------------------------------------------------------+ 2741 Attendee "C" responds to meeting "Organizer" "A" 2743 BEGIN:VCALENDAR 2744 PRODID:-//ACME/DesktopCalendar//EN 2745 METHOD:REPLY 2746 VERSION:2.0 2747 BEGIN:VEVENT 2748 ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED- 2749 TO="Mailto:E@example.com":Mailto:C@example.com 2750 UID:www.acme.com-873970198738777@host.com 2751 SEQUENCE:0 2752 REQUEST-STATUS:2.0;Success 2753 DTSTAMP:19970611T190000Z 2754 END:VEVENT 2755 END:VCALENDAR 2757 Attendee "C" delegates presence at the meeting to "E". 2759 BEGIN:VCALENDAR 2760 PRODID:-//ACME/DesktopCalendar//EN 2761 METHOD:REQUEST 2762 VERSION:2.0 2763 BEGIN:VEVENT 2764 ATTENDEE;ROLE=ORGANIZER:Mailto:A@example.com 2765 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 2766 ATTENDEE;ROLE=DELEGATE;RSVP=TRUE;EXPECT=REQUEST; 2767 DELEGATED-FROM=_Mailto:C@example.com_:Mailto:E@example.com 2768 ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED; 2769 DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com 2770 DTSTART:19970701T110000-0700 2771 DTEND:19970701T113000-0700 2772 SUMMARY:Phone Conference 2773 UID:www.acme.com-873970198738777@host.com 2774 SEQUENCE:0 2775 STATUS:CONFIRMED 2776 DTSTAMP:19970611T190000Z 2777 END:VEVENT 2778 END:VCALENDAR 2780 Silverberg/Mansour/Dawson/Hopson 55 Expires MAY 1998 2781 4.2.6 Delegate Accepts the Meeting 2783 To accept a delegated meeting, the delegate sends the following 2784 message to "A" and "C" 2786 BEGIN:VCALENDAR 2787 PRODID:-//ACME/DesktopCalendar//EN 2788 METHOD:REPLY 2789 VERSION:2.0 2790 BEGIN:VEVENT 2791 ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED; 2792 DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com 2793 UID:www.acme.com-873970198738777@host.com 2794 SEQUENCE:1 2795 REQUEST-STATUS:2.0;Success 2796 DTSTAMP:19970614T190000Z 2797 END:VEVENT 2798 END:VCALENDAR 2800 4.2.7 Delegate Declines the Meeting 2802 In this example the delegate declines the meeting request and sets 2803 the "ATTENDEE" property "STATUS" parameter to DECLINED. The 2804 "Organizer" SHOULD resend the "REQUEST" to "C" with the status of the 2805 delegate set to DECLINED. This lets the "delegator" know that the 2806 "delegate" has declined and provides an opportunity to the 2807 "delegator" to either accept or delegate the request to another 2808 "Calendar User". 2810 Response from "E" to "A" and "C". 2812 BEGIN:VCALENDAR 2813 PRODID:-//ACME/DesktopCalendar//EN 2814 METHOD:REPLY 2815 VERSION:2.0 2816 BEGIN:VEVENT 2817 ATTENDEE;ROLE=ATTENDEE;STATUS=DECLINED; 2818 DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com 2819 UID:www.acme.com-873970198738777@host.com 2820 SEQUENCE:1 2821 REQUEST-STATUS:2.0;Success 2822 DTSTAMP:19970614T190000Z 2823 END:VEVENT 2824 END:VCALENDAR 2826 "A" resends the "REQUEST" method to "C". "A" MAY also wish to express 2827 the fact that the item was delegated in the "COMMENT" property. 2829 BEGIN:VCALENDAR 2830 PRODID:-//ACME/DesktopCalendar//EN 2832 Silverberg/Mansour/Dawson/Hopson 56 Expires MAY 1998 2833 METHOD:REPLY 2834 VERSION:2.0 2835 BEGIN:VEVENT 2836 ATTENDEE;ROLE=ATTENDEE;STATUS=DECLINED; 2837 DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com 2838 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:C@example. 2839 com 2840 UID:www.acme.com-873970198738777@host.com 2841 SEQUENCE:2 2842 REQUEST-STATUS:2.0;Success 2843 DTSTAMP:19970614T200000Z 2844 COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR 2845 INVITATION 2846 END:VEVENT 2847 END:VCALENDAR 2849 4.2.8 Forwarding an Event Request 2851 The protocol does not prevent an "Attendee" from "forwarding" an 2852 "VEVENT" calendar component to other "Calendar Users". Forwarding 2853 differs from delegation in that the forwarded "Calendar User" (often 2854 referred to as a "Party Crasher") does not replace the forwarding 2855 "Calendar User". Implementations are not required to add the "Party 2856 Crasher" to the "Attendee" list and hence there is no guarantee that 2857 a "Party Crasher" will receive additional updates to the Event. The 2858 forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the 2859 attendee list. 2861 4.2.9 Cancel A Group Event 2863 Individual "A" requests a meeting between individuals "A", "B" and 2864 "C". Individual "B" declines attendance to the meeting. Individual 2865 "A" decides to cancel the meeting. The following table illustrates 2866 the sequence of messages that would be exchanged between these 2867 individuals. 2869 Messages related to a previously canceled event ("SEQUENCE" property 2870 value is less than the "SEQUENCE" property value of the "CANCEL" 2871 message) or "VTODO" calendar component MUST be ignored. 2873 +--------------------------------------------------------------------+ 2874 | Action | "Organizer" | Attendee | 2875 +--------------------------------------------------------------------+ 2876 | Initiate a meeting | "A" sends a REQUEST | | 2877 | request | message to "B" and | | 2878 | | and "C" | | 2879 +--------------------------------------------------------------------+ 2880 | Decline the meeting| | "B" sends a REPLY | 2881 | request | | message to "A" with its | 2882 | | | ATTENDEE STATUS para- | 2883 | | | set to "DECLINED". | 2885 Silverberg/Mansour/Dawson/Hopson 57 Expires MAY 1998 2886 +--------------------------------------------------------------------+ 2887 | Cancel the meeting | "A" sends a CANCEL | | 2888 | | message to "B" and | | 2889 | | "C" | | 2890 +--------------------------------------------------------------------+ 2892 The example shows how "A" cancels the event. 2894 BEGIN:VCALENDAR 2895 PRODID:-//ACME/DesktopCalendar//EN 2896 METHOD:CANCEL 2897 VERSION:2.0 2898 BEGIN:VEVENT 2899 COMMENT:Mr. B cannot attend. I'll reschedule the meeting later. 2900 UID:www.acme.com-873970198738777@host.com 2901 SEQUENCE:0 2902 DTSTAMP:19970613T190000Z 2903 STATUS:CANCELLED 2904 END:VEVENT 2905 END:VCALENDAR 2907 The "Organizer" of a meeting MAY "uninvite" or remove "Attendees" by 2908 sending a "CANCEL" method to only those "Attendees". 2910 4.3 Busy Time Examples 2912 Individual "A" requests busy time from individuals "B", "C" and "D". 2913 Individual "B" and "C" replies with busy time data to individual "A". 2914 Individual "D" does not support busy time requests and does not reply 2915 with any data. 2917 The following table illustrates the sequence of messages that would 2918 be exchanged between these individuals. 2920 +--------------------------------------------------------------------+ 2921 | Action | "Organizer" | Attendee | 2922 +--------------------------------------------------------------------+ 2923 | Initiate a busy | "A" sends a REQUEST | | 2924 | time request | message to "B" and | | 2925 | | and "C" | | 2926 +--------------------------------------------------------------------+ 2927 | Reply to the busy | | "B" sends a REPLY | 2928 | request with busy | | message to "A" with | 2929 | time data | | busy time data | 2930 +--------------------------------------------------------------------+ 2932 4.3.1 Request Busy Time 2934 "A" sends a BUSY-"REQUEST" to "B" and "C" for busy time 2936 Silverberg/Mansour/Dawson/Hopson 58 Expires MAY 1998 2937 BEGIN:VCALENDAR 2938 PRODID:-//ACME/DesktopCalendar//EN 2939 METHOD:REQUEST 2940 VERSION:2.0 2941 BEGIN:VFREEBUSY 2942 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 2943 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 2944 ATTENDEE:Mailto:B@example.com 2945 ATTENDEE:Mailto:C@example.com 2946 DTSTAMP:19970613T190000Z 2947 DTSTART:19970701T080000-0700 2948 DTEND:19970701T200000-0700 2949 UID:www.acme.com-873970198738777@host.com 2950 END:VFREEBUSY 2951 END:VCALENDAR 2953 4.3.2 Reply To A Busy Time Request 2955 "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component 2956 to "A" 2958 BEGIN:VCALENDAR 2959 PRODID:-//ACME/DesktopCalendar//EN 2960 METHOD:REPLY 2961 VERSION:2.0 2962 BEGIN:VFREEBUSY 2963 ATTENDEE:Mailto:B@example.com 2964 DTSTART:19970701T080000-0700 2965 DTEND:19970701T200000-0700 2966 UID:www.acme.com-873970198738777@host.com 2967 FREEBUSY:19970701T090000-0700/PT1H,19970701T140000-0700/PT30H 2968 DTSTAMP:19970613T190030Z 2969 END:VFREEBUSY 2970 END:VCALENDAR 2972 B is busy from 09:00 to 10:00 and from 14:00 to 14:30. 2974 4.4 Recurring Event and Time Zone Examples 2976 4.4.1 A Recurring Event Spanning Time Zones 2978 This event describes a weekly phone conference. The "Attendees" are 2979 each in a different time zone. 2981 BEGIN:VCALENDAR 2983 PRODID:-//ACME/DesktopCalendar//EN 2984 METHOD:REQUEST 2986 Silverberg/Mansour/Dawson/Hopson 59 Expires MAY 1998 2987 VERSION:2.0 2989 BEGIN:VTIMEZONE 2990 DAYLIGHT:TRUE 2991 DTSTART:19970406T200000-0800 2992 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 2993 TZNAME:PDT 2994 TZOFFSET:-0700 2995 END:VTIMEZONE 2997 BEGIN:VTIMEZONE 2998 DAYLIGHT:FALSE 2999 DTSTART:19971026T200000-0700 3000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3001 TZNAME:PST 3002 TZOFFSET:-0800 3003 END:VTIMEZONE 3005 BEGIN:VEVENT 3006 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:Mailto:A@example.com 3007 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@example.fr 3008 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:c@example.jp 3009 DTSTAMP:19970613T190030Z 3010 DTSTART:19970701T140000 3011 DTEND:19970701T150000 3012 RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU 3013 RDATE:19970910T140000 3014 EXDATE:19970909T140000 3015 EXDATE:19971028T150000 3016 SUMMARY:Weekly Phone Conference 3017 UID:www.acme.com-873970198738777@host.com 3018 SEQUENCE:0 3019 STATUS:CONFIRMED 3020 END:VEVENT 3022 END:VCALENDAR 3024 The "VTIMEZONE" components SHOULD appear in an iCalendar object 3025 containing recurring events. This is especially important if a 3026 recurring event has "Attendees" in different time zones. There MAY be 3027 multiple VTIMEZONE components in an iCalendar object, however, they 3028 MUST be used to define the same time zone. That is, there cannot be 3029 VTIMEZONE components describing both PST/PDT and EST/EDT at the 3030 component level in the same iCalendar object. 3032 The first two components of this iCalendar object are the time zone 3033 components. The "DTSTART" date coincides with the first instance of 3034 the RRULE property. 3036 The recurring meeting is defined in a particular time zone, 3037 presumably that of the originator. The client for each "Attendee" has 3038 the responsibility of determining the recurrence time in the 3039 "Attendee's" time zone. 3041 Silverberg/Mansour/Dawson/Hopson 60 Expires MAY 1998 3042 The repeating event starts on Tuesday, July 1, 1997 at 2:00pm. Since 3043 no time zone is specified in the "DTSTART" property, the time zone 3044 component of PDT applies to the start and end times. "Attendee" 3045 B@example.fr is in France where the local time on this date is 7 3046 hours later than PDT or 21:00. "Attendee" C@example.jp is in Japan 3047 where local time is 9 hours ahead of than UTC or Wednesday, July 2 at 3048 07:00. The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE" 3049 property results in 20 instances. The last instance falls on Tuesday, 3050 November 11, 1997 2:00pm PST. The "RDATE" property adds another 3051 instance: WED, 10-SEP-1997 21:00 GMT. 3053 There are two exceptions to this recurring appointment. The first one 3054 is: 3056 TUE, 09-SEP-1997 21:00 GMT 3057 TUE, 09-SEP-1997 14:00 PDT 3058 WED, 10-SEP-1997 07:00 JDT 3060 and the second is: 3062 TUE, 28-OCT-1997 22:00 GMT 3063 TUE, 28-OCT-1997 14:00 PST 3064 WED, 29-OCT-1997 07:00 JST 3066 4.4.2 Modify A Recurring Instance 3068 In this example the "Organizer" issues a recurring meeting. Later the 3069 "Organizer" changes an instance of the event by changing the 3070 "DTSTART" property. Note the use of "RECURRENCE-ID" property and 3071 "SEQUENCE" property in the second request. 3073 Original Request: 3075 BEGIN:VCALENDAR 3076 METHOD:REQUEST 3077 PRODID:-//RDU Software//NONSGML HandCal//EN 3078 VERSION:2.0 3079 BEGIN:VEVENT 3080 CREATED:19970526T083000 3081 UID:guid-1@host1.com 3082 SEQUENCE:0 3083 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z 3084 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3085 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3086 ATTENDEE;EXPECT=REQUEST:Mailto:B@example.com 3087 ATTENDEE;EXPECT=REQUEST:Mailto:C@example.com 3088 ATTENDEE;EXPECT=REQUEST:Mailto:D@example.com 3089 DESCRIPTION:IETF-C&S Conference Call 3090 CLASS:PUBLIC 3091 SUMMARY:IETF Calendaring Working Group Meeting 3092 DTSTART:19970601T210000Z 3093 DTEND:19970601T220000Z 3094 LOCATION:Conference Call 3096 Silverberg/Mansour/Dawson/Hopson 61 Expires MAY 1998 3097 DTSTAMP:19970526T083000 3098 STATUS:CONFIRMED 3099 END:VEVENT 3100 END:VCALENDAR 3102 The event request below is to change a time and create an exception. 3103 This creates an exception on July 3rd. 3105 BEGIN:VCALENDAR 3106 METHOD:REQUEST 3107 PRODID:-//RDU Software//NONSGML HandCal//EN 3108 VERSION:2.0 3109 BEGIN:VEVENT 3110 CREATED:19970526T083000 3111 UID:guid-1@host1com 3112 RECURRENCE-ID:19970701T210000Z 3113 SEQUENCE:1 3114 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z 3115 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3116 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3117 ATTENDEE;EXPECT=REQUEST:Mailto:B@example.com 3118 ATTENDEE;EXPECT=REQUEST:Mailto:C@example.com 3119 ATTENDEE;EXPECT=REQUEST:Mailto:D@example.com 3120 DESCRIPTION:IETF-C&S Conference Call 3121 CLASS:PUBLIC 3122 SUMMARY:IETF Calendaring Working Group Meeting 3123 DTSTART:19970703T210000Z 3124 DTEND:19970703T220000Z 3125 LOCATION:Conference Call 3126 DTSTAMP:19970626T093000 3127 STATUS:CONFIRMED 3128 END:VEVENT 3129 END:VCALENDAR 3131 4.4.3 Cancel A Recurring Instance 3133 In this example the "Organizer" of a recurring event wishes to delete 3134 an instance. This is referred to as an "exception" to the recurring 3135 event. 3137 BEGIN:VCALENDAR 3138 METHOD:CANCEL 3139 PRODID:-//RDU Software//NONSGML HandCal//EN 3140 VERSION:2.0 3141 BEGIN:VEVENT 3142 UID:guid-1@host1.com 3143 RECURRENCE-ID:19970801T210000Z 3144 SEQUENCE:2 3145 DTSTAMP:19970721T093000 3146 STATUS:CANCELLED 3147 END:VEVENT 3149 Silverberg/Mansour/Dawson/Hopson 62 Expires MAY 1998 3150 END:VCALENDAR 3152 4.4.4 Cancel An Exception 3154 In the following example, the "Organizer" has created an exception 3155 (as in 4.4.3) and now wishes to cancel it. In this case a "CANCEL" 3156 method is sent with the specific "RECURRENCE-ID", "UID" and 3157 "SEQUENCE" properties of the exception. This same sequence MAY be 3158 used to decline a previously accepted modification to a recurring 3159 event (as in 4.4.2). 3161 BEGIN:VCALENDAR 3162 METHOD:CANCEL 3163 PRODID:-//RDU Software//NONSGML HandCal//EN 3164 VERSION:2.0 3165 BEGIN:VEVENT 3166 UID:guid-1@host1.com 3167 RECURRENCE-ID:19970801T210000Z 3168 SEQUENCE:2 3169 DTSTAMP:19970721T103000 3170 STATUS:CANCELLED 3171 END:VEVENT 3172 END:VCALENDAR 3174 4.4.5 Cancel Recurring Event 3176 In this example the "Organizer" wishes to cancel the entire recurring 3177 event and any child exceptions. 3179 BEGIN:VCALENDAR 3180 METHOD:CANCEL 3181 PRODID:-//RDU Software//NONSGML HandCal//EN 3182 VERSION:2.0 3183 BEGIN:VEVENT 3184 UID:guid-1@host1.com 3185 DTSTAMP:19970721T103000 3186 SEQUENCE:2 3187 STATUS:CANCELLED 3188 END:VEVENT 3189 END:VCALENDAR 3191 4.4.6 Change All Future Instances 3193 This example changes the meeting location from a conference call to 3194 Seattle starting Sept 1 and extends to all future instances. 3196 BEGIN:VCALENDAR 3197 METHOD:REQUEST 3199 Silverberg/Mansour/Dawson/Hopson 63 Expires MAY 1998 3200 PRODID:-//RDU Software//NONSGML HandCal//EN 3201 VERSION:2.0 3202 BEGIN:VEVENT 3203 CREATED:19970526T083000 3204 UID:guid-1@host1.com 3205 RECURRENCE-ID;THISANDFUTURE:19970901T210000Z 3206 SEQUENCE:3 3207 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z 3208 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3209 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3210 ATTENDEE;EXPECT=REQUEST:Mailto:B@example.com 3211 ATTENDEE;EXPECT=REQUEST:Mailto:C@example.com 3212 ATTENDEE;EXPECT=REQUEST:Mailto:D@example.com 3213 DESCRIPTION:IETF-C&S Conference Call 3214 CLASS:PUBLIC 3215 SUMMARY:IETF Calendaring Working Group Meeting 3216 DTSTART:19970901T210000Z [SS2][SS3] 3217 DTEND:19970901T220000Z 3218 LOCATION:Building 32, Microsoft, Seattle, WA 3219 DTSTAMP:19970526T083000 3220 STATUS:CONFIRMED 3221 END:VEVENT 3222 END:VCALENDAR 3224 4.4.7 Add A New Instance To A Recurring Event 3226 This example adds a one-time additional instance to the recurring 3227 event. "Organizer" adds a second July meeting on the 15th. 3229 BEGIN:VCALENDAR 3230 METHOD:REQUEST 3231 PRODID:-//RDU Software//NONSGML HandCal//EN 3232 VERSION:2.0 3233 BEGIN:VEVENT 3234 CREATED:19970526T083000 3235 UID:guid-1@host1.com 3236 RECURRENCE-ID:19970715T210000Z 3237 SEQUENCE:4 3238 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z 3239 RDATE;VALUE=PERIOD:19970715T210000Z/19970715T220000Z 3240 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3241 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3242 ATTENDEE;EXPECT=REQUEST:Mailto:B@example.com 3243 ATTENDEE;EXPECT=REQUEST:Mailto:C@example.com 3244 ATTENDEE;EXPECT=REQUEST:Mailto:D@example.com 3245 DESCRIPTION:IETF-C&S Conference Call 3246 CLASS:PUBLIC 3247 SUMMARY:IETF Calendaring Working Group Meeting 3248 DTSTART:19970715T210000Z 3249 DTEND:19970715T220000Z 3250 LOCATION:Conference Call 3251 DTSTAMP:19970629T093000 3253 Silverberg/Mansour/Dawson/Hopson 64 Expires MAY 1998 3254 STATUS:CONFIRMED 3255 END:VEVENT 3256 END:VCALENDAR 3258 4.4.8 Counter An Instance Of A Recurring Event 3260 In this example one of the "Attendees" counters the "DTSTART" 3261 property of the proposed second July meeting. 3263 BEGIN:VCALENDAR 3264 METHOD:COUNTER 3265 PRODID:-//RDU Software//NONSGML HandCal//EN 3266 VERSION:2.0 3267 BEGIN:VEVENT 3268 CREATED:19970526T083000 3269 UID:guid-1@host1.com 3270 RECURRENCE-ID:19970715T210000Z 3271 SEQUENCE:4 3272 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z 3273 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3274 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3275 ATTENDEE;EXPECT=REQUEST:Mailto:B@example.com 3276 ATTENDEE;EXPECT=REQUEST:Mailto:C@example.com 3277 ATTENDEE;EXPECT=REQUEST:Mailto:D@example.com 3278 DESCRIPTION:IETF-C&S Conference Call 3279 CLASS:PUBLIC 3280 SUMMARY:IETF Calendaring Working Group Meeting 3281 DTSTART:19970715T220000Z 3282 DTEND:19970715T230000Z 3283 LOCATION:Conference Call 3284 COMMENT:May we bump this by an hour? I have a conflict 3285 DTSTAMP:19970629T094000 3286 END:VEVENT 3287 END:VCALENDAR 3289 4.4.9 Error Reply To A request 3291 The following example illustrates a scenario where a meeting is 3292 proposed that contains a property that is not supported (in this 3293 case, the "RRULE" property). 3295 Original Request: 3297 BEGIN:VCALENDAR 3298 METHOD:REQUEST 3299 PRODID:-//RDU Software//NONSGML HandCal//EN 3300 VERSION:2.0 3301 BEGIN:VEVENT 3302 CREATED:19970526T083000 3303 UID:guid-1@host1.com 3305 Silverberg/Mansour/Dawson/Hopson 65 Expires MAY 1998 3306 SEQUENCE:0 3307 RRULE:FREQ=MONTHLY;BYMONTHDAY=1 3308 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3309 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3310 ATTENDEE;EXPECT=REQUEST:Mailto:B@example.com 3311 ATTENDEE;EXPECT=REQUEST:Mailto:C@example.com 3312 ATTENDEE;EXPECT=REQUEST:Mailto:D@example.com 3313 DESCRIPTION:IETF-C&S Conference Call 3314 CLASS:PUBLIC 3315 SUMMARY:IETF Calendaring Working Group Meeting 3316 DTSTART:19970601T210000Z 3317 DTEND:19970601T220000Z 3318 DTSTAMP:19970602T094000 3319 LOCATION:Conference Call 3320 STATUS:CONFIRMED 3321 END:VEVENT 3322 END:VCALENDAR 3324 Response to indicate that RRULE is not supported: 3326 BEGIN:VCALENDAR 3327 PRODID:-//RDU Software//NONSGML HandCal//EN 3328 METHOD:REPLY 3329 VERSION:2.0 3330 BEGIN:VEVENT 3331 REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single 3332 event;RRULE 3333 UID:guid-1@host1.com 3334 SEQUENCE:0 3335 DTSTAMP:19970603T094000 3336 END:VEVENT 3337 END:VCALENDAR 3339 4.5 Group To-do Examples 3341 Individual "A" creates a group task in which individuals "A", "B", 3342 "C" and "D" will participate. Individual "B" confirms acceptance of 3343 the task. Individual "C" declines the task. Individual "D" 3344 tentatively accepts the task. The following table illustrates the 3345 sequence of messages that would be exchanged between these 3346 individuals. Individual "A" then issues a "REFRESH" method to obtain 3347 the status of the to-do from each participant. The response indicates 3348 the individual "Attendee's" completion status. The table below 3349 illustrates the message flow. 3351 +--------------------------------------------------------------------+ 3352 | Action | "Organizer" | Attendee | 3353 +--------------------------------------------------------------------+ 3354 | Initiate a to-do | "A" sends a REQUEST | | 3355 | request | message to "B", "C",| | 3356 | | and "D" | | 3358 Silverberg/Mansour/Dawson/Hopson 66 Expires MAY 1998 3359 +--------------------------------------------------------------------+ 3360 | Accept the to-do | | "B" sends a REPLY | 3361 | request | | message to "A" with its | 3362 | | | ATTENDEE STATUS para- | 3363 | | | set to "ACCEPTED". | 3364 +--------------------------------------------------------------------+ 3365 | Decline the to-do | | "C" sends a REPLY | 3366 | request | | message to "A" with its | 3367 | | | ATTENDEE STATUS para- | 3368 | | | set to "DECLINED". | 3369 +--------------------------------------------------------------------+ 3370 | Tentatively accept | | "D" sends a REPLY | 3371 | the to-do request | | message to "A" with its | 3372 | | | ATTENDEE STATUS para- | 3373 | | | set to "TENTATIVE". | 3374 +--------------------------------------------------------------------+ 3375 | Check attendee | "A" sends a REFRESH | | 3376 | completion status | message to "B" and | | 3377 | | "C" with current | | 3378 | | information. | | 3379 +--------------------------------------------------------------------+ 3380 | Attendee indicates | | "B" sends a REPLY | 3381 | percent complete | | message indicating | 3382 | | | percent complete | 3383 +--------------------------------------------------------------------+ 3384 | Attendee indicates | | "C" sends a REPLY | 3385 | completion | | message indicating | 3386 | | | completion | 3387 +--------------------------------------------------------------------+ 3389 4.5.1 A VTODO Request 3391 A sample "REQUEST" with for a "VTODO" calendar component that "A" 3392 sends to "B", "C", and "D". 3394 BEGIN:VCALENDAR 3395 PRODID:-//ACME/DesktopCalendar//EN 3396 METHOD:REQUEST 3397 VERSION:2.0 3398 BEGIN:VTODO 3399 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3400 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3401 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:B@example. 3402 com 3403 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:C@example. 3404 com 3405 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:D@example. 3406 com 3407 DTSTART:19970701T100000-0700 3408 DUE:19970722T100000-0700 3409 SUMMARY:Create the requirements document 3410 UID:www.acme.com-873970198738777-00@host.com 3412 Silverberg/Mansour/Dawson/Hopson 67 Expires MAY 1998 3413 SEQUENCE:0 3414 DTSTAMP:19970717T200000Z 3415 STATUS:CONFIRMED 3416 END:VTODO 3417 END:VCALENDAR 3419 4.5.2 A VTODO Reply 3421 Attendee "B" accepts the meeting. 3423 BEGIN:VCALENDAR 3424 PRODID:-//ACME/DesktopCalendar//EN 3425 METHOD:REPLY 3426 VERSION:2.0 3427 BEGIN:VTODO 3428 ATTENDEE;STATUS=ACCEPTED:Mailto:B@example.com 3429 UID:www.acme.com-873970198738777-00@host.com 3430 COMMENT:I'll send you my input by e-mail 3431 SEQUENCE:0 3432 DTSTAMP:19970717T203000Z 3433 REQUEST-STATUS:2.0;Success 3434 END:VTODO 3435 END:VCALENDAR 3437 "B" could have declined the meeting or indicated tentative acceptance 3438 by setting the "ATTENDEE;STATUS=" property parameter sequence to 3439 DECLINED or TENTATIVE, respectively. 3441 4.5.3 A VTODO Refresh 3443 "A" requests status from all "Attendees". 3445 BEGIN:VCALENDAR 3446 PRODID:-//ACME/DesktopCalendar//EN 3447 METHOD:REFRESH 3448 VERSION:2.0 3449 BEGIN:VTODO 3450 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3451 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3452 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:B@example. 3453 com 3454 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:C@example. 3455 com 3456 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:D@example. 3457 com 3458 UID:www.acme.com-873970198738777-00@host.com 3459 DTSTAMP:19970717T230000Z 3460 END:VTODO 3461 END:VCALENDAR 3463 Silverberg/Mansour/Dawson/Hopson 68 Expires MAY 1998 3464 4.5.4 A Refresh Reply: Percent-Complete 3466 A reply indicating that the task in being worked on and that "B" is 3467 75% complete with "B's" part of the assignment. 3469 BEGIN:VCALENDAR 3470 PRODID:-//ACME/DesktopCalendar//EN 3471 METHOD:REPLY 3472 VERSION:2.0 3473 BEGIN:VTODO 3474 ATTENDEE;STATUS=IN-PROCESS:Mailto:B@example.com 3475 PERCENT-COMPLETE:75 3476 UID:www.acme.com-873970198738777-00@host.com 3477 DTSTAMP:19970717T233000Z 3478 SEQUENCE:0 3479 END:VTODO 3480 END:VCALENDAR 3482 4.5.5 A Refresh Reply: Completed 3484 A reply indicating that "C" finished with "C's" part of the 3485 assignment. 3487 BEGIN:VCALENDAR 3488 PRODID:-//ACME/DesktopCalendar//EN 3489 METHOD:REPLY 3490 VERSION:2.0 3491 BEGIN:VTODO 3492 ATTENDEE;STATUS=COMPLETED:Mailto:C@example.com 3493 UID:www.acme.com-873970198738777-00@host.com 3494 DTSTAMP:19970717T233000Z 3495 SEQUENCE:0 3496 END:VTODO 3497 END:VCALENDAR 3499 4.5.6 An Updated VTODO Request 3501 Owner "A" resends the "VTODO" calendar component. "A" set's the 3502 overall completion for the to-do at 40%. 3504 BEGIN:VCALENDAR 3505 PRODID:-//ACME/DesktopCalendar//EN 3506 METHOD:REQUEST 3507 VERSION:2.0 3508 BEGIN:VTODO 3509 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3510 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3511 ATTENDEE;STATUS=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B@example.com 3512 ATTENDEE;STATUS=COMPLETED;TYPE=INDIVIDUAL:Mailto:C@example.com 3514 Silverberg/Mansour/Dawson/Hopson 69 Expires MAY 1998 3515 ATTENDEE;STATUS=TENTATIVE;TYPE=INDIVIDUAL:Mailto:D@example.com 3516 DTSTART:19970701T100000-0700 3517 DUE:19970722T100000-0700 3518 SUMMARY:Create the requirements document 3519 UID:www.acme.com-873970198738777-00@host.com 3520 SEQUENCE:1 3521 DTSTAMP:19970718T100000Z 3522 STATUS:IN-PROGRESS 3523 PERCENT-COMPLETE:40 3524 END:VTODO 3525 END:VCALENDAR 3527 4.5.7 A Recurring VTODOs 3529 The following examples relate to recurring "VTODO" calendar 3530 components. 3532 4.5.7.1 Request for a Recurring VTODO 3534 In this example "A" sends a recurring "VTODO" calendar component to 3535 "B" and "C". 3537 BEGIN:VCALENDAR 3538 PRODID:-//ACME/DesktopCalendar//EN 3539 METHOD:REQUEST 3540 VERSION:2.0 3541 BEGIN:VTODO 3542 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3543 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3544 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:B@example. 3545 com 3546 ATTENDEE;RSVP=TRUE;EXPECT=REQUEST;TYPE=INDIVIDUAL:Mailto:C@example. 3547 com 3548 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR 3549 DTSTART:19980101T100000-0700 3550 DUE:19980103T100000-0700 3551 SUMMARY:Send Status Reports to Area Managers 3552 UID:www.acme.com-873970198738777-00@host.com 3553 SEQUENCE:0 3554 DTSTAMP:19970717T200000Z 3555 STATUS:CONFIRMED 3556 END:VTODO 3557 END:VCALENDAR 3559 4.5.7.2 Calculating due dates in recurring VTODOs 3561 The due date in a recurring "VTODO" calendar component is either a 3562 fixed interval specified in the "REQUEST" method or specified 3563 specifically using the "RECURRENCE-ID" property. The former is 3565 Silverberg/Mansour/Dawson/Hopson 70 Expires MAY 1998 3566 calculated by applying the difference between "DTSTART" and "DUE" 3567 properties and applying it to each of the start of each recurring 3568 instance. Hence, if the initial "VTODO" calendar component specifies 3569 a "DTSTART" property value of "19970701T190000Z" and a "DUE" property 3570 value of "19970801T190000Z" the interval of one day which could be 3571 applied to each recurring instance of the "VTODO" calendar component. 3573 4.5.7.3 Replying to an instance of a recurring VTODO 3575 In this example "B" updates "A" on a single instance of the "VTODO" 3576 calendar component. 3578 BEGIN:VCALENDAR 3579 PRODID:-//ACME/DesktopCalendar//EN 3580 METHOD:REPLY 3581 VERSION:2.0 3582 BEGIN:VTODO 3583 ATTENDEE;STATUS=IN-PROCESS:Mailto:B@example.com 3584 PERCENT-COMPLETE:75 3585 UID:www.acme.com-873970198738777-00@host.com 3586 DTSTAMP:19970717T233000Z 3587 RECURRENCE-ID:19980101T100000-0700 3588 SEQUENCE:0 3589 END:VTODO 3590 END:VCALENDAR 3592 4.6 Journal Examples 3594 The iCalendar object below describes a single journal entry for 3595 October 2, 1997. The "RELATED-TO" property references the phone 3596 conference event for which minutes were taken. 3598 BEGIN:VCALENDAR 3599 PROFILE:PUBLISH 3600 PRODID:-//ACME/DesktopCalendar//EN 3601 VERSION:2.0 3602 BEGIN:VJOURNAL 3603 DTSTART:19971002T200000Z 3604 SUMMARY:Phone conference minutes 3605 DESCRIPTION:The editors meeting was held on October 1, 1997. 3606 Details are in the attached document. 3607 UID:0981234-1234234-2410@host.com 3608 RELATED-TO:0981234-1234234-2402-35@host.com 3609 ATTACH:ftp\://ftp.example.com/pub/ed/minutes100197.txt 3610 END:VJOURNAL 3611 END:VCALENDAR 3613 Silverberg/Mansour/Dawson/Hopson 71 Expires MAY 1998 3614 4.7 Other Examples 3616 4.7.1 Event Refresh 3618 Refresh the event with "UID" property value of "guid-1- 3619 12345@host1.com": 3621 BEGIN:VCALENDAR 3622 PRODID:-//RDU Software//NONSGML HandCal//EN 3623 METHOD:REFRESH 3624 VERSION:2.0 3625 BEGIN:VEVENT 3626 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3627 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3628 ATTENDEE;EXPECT=REQUEST:Mailto:B@example.com 3629 ATTENDEE;EXPECT=REQUEST:Mailto:C@example.com 3630 ATTENDEE;EXPECT=REQUEST:Mailto:D@example.com 3631 UID: guid-1-12345@host1.com 3632 DTSTAMP:19970603T094000 3633 END:VEVENT 3634 END:VCALENDAR 3636 4.7.2 Bad RECURRENCE-ID 3638 If an "Attendee" receives a request that references a "RECURRENCE-ID" 3639 property that can not be found, the "Attendee" SHOULD send a 3640 "REFRESH" method back to the "Organizer" for the latest copy of the 3641 event. 3643 +--------------------------------------------------------------------+ 3644 | Action | "Organizer" | Attendee | 3645 +--------------------------------------------------------------------+ 3646 | Update an instance | "A" sends a REQUEST | | 3647 | request | message to "B" | | 3648 +--------------------------------------------------------------------+ 3649 | Attendee requests | | "B" sends a REFRESH | 3650 | refresh because | | message to "A" | 3651 | RecurrenceID was | | | 3652 | not found | | | 3653 +--------------------------------------------------------------------+ 3654 | Refresh the entire | "A" sends the | | 3655 | Event | latest copy of the | | 3656 | | Event to "B" | | 3657 +--------------------------------------------------------------------+ 3658 | Attendee handles | | "B" updates to the | 3659 | the request and | | latest copy of the | 3660 | updates the | | meeting. | 3661 | instance | | | 3662 +--------------------------------------------------------------------+ 3664 Silverberg/Mansour/Dawson/Hopson 72 Expires MAY 1998 3665 Request from "A": 3667 BEGIN:VCALENDAR 3668 METHOD:REQUEST 3669 PRODID:-//RDU Software//NONSGML HandCal//EN 3670 VERSION:2.0 3671 BEGIN:VEVENT 3672 UID:acme-12345@host1.com 3673 SEQUENCE:3 3674 RRULE:FREQ=WEEKLY 3675 RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z 3676 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3677 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3678 ATTENDEE;EXPECT=REQUEST:Mailto:B@example.com 3679 DESCRIPTION:IETF-C&S Conference Call 3680 SUMMARY:IETF Calendaring Working Group Meeting 3681 DTSTART:19970801T210000Z 3682 DTEND:19970801T220000Z 3683 DTSTAMP:19970726T083000 3684 STATUS:CONFIRMED 3685 END:VEVENT 3686 END:VCALENDAR 3688 "B" has the event with "UID" property"acme-12345@host1.com" but the 3689 "SEQUENCE" property value is "1" and the event does not have an 3690 instance at the specified recurrence time. This means that the 3691 "Owner" is either adding a new instance or that the new instance was 3692 added when "SEQUENCE" property value "2" of the event was generated. 3693 In either case, "B" needs a new copy of the event. 3695 BEGIN:VCALENDAR 3696 PRODID:-//RDU Software//NONSGML HandCal//EN 3697 METHOD:REFRESH 3698 VERSION:2.0 3699 BEGIN:VEVENT 3700 ATTENDEE;ROLE=OWNER:Mailto:A@example.com 3701 ATTENDEE;ROLE=ATTENDEE;STATUS=ACCEPTED:Mailto:A@example.com 3702 ATTENDEE;EXPECT=REQUEST:Mailto:B@example.com 3703 UID:acme-12345@host1.com 3704 DTSTAMP:19970603T094000 3705 END:VEVENT 3706 END:VCALENDAR 3708 5 Application Protocol Fallbacks 3710 5.1 Partial Implementation 3712 Applications that support this memo are not required to support the 3713 entire protocol. The following describes how methods and properties 3714 SHOULD "fallback" in applications that do not support the complete 3716 Silverberg/Mansour/Dawson/Hopson 73 Expires MAY 1998 3717 protocol. If a method or property is not addressed in this section, 3718 it MAY be ignored. 3720 5.1.1 Event-Related Fallbacks 3722 Method Fallback 3723 -------------- ----------------------------------------------------- 3724 PUBLISH Required. 3725 CANCEL Required. 3726 REQUEST PUBLISH 3727 REPLY Required. 3728 DELEGATE Reply with Not Supported. 3729 REQUEST Reply with Not Supported. 3730 REPLY Reply with Not Supported. 3731 COUNTER Reply with Not Supported 3732 DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise 3733 reply with Not Supported. 3735 iCalendar 3736 Property Fallback 3737 -------------- ----------------------------------------------------- 3738 CALSCALE Ignore; assume GREGORIAN. 3739 GEO Ignore. 3740 PRODID Ignore. 3741 METHOD Required as described in the Method list above. 3742 SOURCE Ignore 3743 NAME Ignore. 3744 VERSION Ignore. 3746 Event-Related 3747 Components Fallback 3748 -------------- ----------------------------------------------------- 3749 VFREEBUSY Reply with Not Supported. 3750 VALARM Reply with Not Supported. 3751 VTIMEZONE Required if RRULE or RDATE is implemented; otherwise 3752 ignore and use local time. 3754 Component 3755 Property Fallback 3756 -------------- ----------------------------------------------------- 3757 ATTACH Ignore. 3758 ATTENDEE Required if EVENT-REQUEST is not implemented; 3759 otherwise reply with Not Supported. 3760 CATEGORIES Required if in VALARM and VALARM is implemented, 3761 otherwise ignore. 3762 CLASS Ignore. 3763 COMMENT Ignore. 3764 COMPLETED Ignore. 3765 CREATED Ignore. 3766 DAYLIGHT Required if VTIMEZONE is implemented; otherwise 3767 Ignore. 3768 DESCRIPTION Required. 3769 DELEGATED-FROM Required if EVENT-DELEGATE is implemented; otherwise 3771 Silverberg/Mansour/Dawson/Hopson 74 Expires MAY 1998 3772 Ignore. 3773 DELEGATED-TO Required if EVENT-DELEGATE is implemented; otherwise 3774 Ignore. 3775 DUE Ignore. 3776 DURATION Reply with Not Supported. 3777 DTSTAMP Required. 3778 DTSTART Required. 3779 DTEND Required. 3780 EXDATE Ignore. 3781 EXRULE Ignore. 3782 FREEBUSY Reply with Not Supported. 3783 LAST-MODIFIED Ignore. 3784 LOCATION Required. 3785 PRIORITY Ignore. 3786 RELATED-TO Ignore. 3787 RDATE Ignore. If implemented, VTIMEZONE MUST also be 3788 implemented. 3789 RRULE Ignore. The first instance occurs on the DTStart 3790 property. 3791 RECURRENCE-ID Required if RRULE is implemented; otherwise Ignore. 3792 REQUEST-STATUS Required. 3793 RESOURCES Ignore. 3794 SEQUENCE Required. 3795 STATUS Ignore. 3796 SUMMARY Ignore. 3797 TRANSP Required if FREEBUSY is implemented; otherwise Ignore. 3798 TZNAME Required if VTIMEZONE is implemented; otherwise 3799 Ignore. 3800 TZOFFSET Required if VTIMEZONE is implemented; otherwise 3801 Ignore. 3802 URL Ignore. 3803 UID Required. 3804 X- Ignore. 3806 5.1.2 To-Do-Related Fallbacks 3808 Method Fallback 3809 -------------- ----------------------------------------------------- 3810 PUBLISH Required. 3811 CANCEL Required. 3812 REQUEST TODO-PUBLISH 3813 REPLY Required. 3815 iCalendar 3816 Property Fallback 3817 -------------- ----------------------------------------------------- 3818 CALSCALE Ignore; assume GREGORIAN. 3819 GEO Ignore. 3820 PRODID Ignore. 3821 METHOD Required as described in the Method list above. 3822 SOURCE Ignore 3823 NAME Ignore. 3825 Silverberg/Mansour/Dawson/Hopson 75 Expires MAY 1998 3826 VERSION Ignore. 3828 To-Do-Related 3829 Components Fallback 3830 -------------- ----------------------------------------------------- 3831 VALARM Reply with Not Supported. 3832 VTIMEZONE Required if RRULE or RDATE is implemented; 3833 otherwise ignore and use local time. 3835 Component 3836 Property Fallback 3837 -------------- ----------------------------------------------------- 3838 CALSCALE Ignore; assume GREGORIAN. 3839 GEO Ignore. 3840 PRODID Ignore. 3841 PROFILE Required as described in the Method list above. 3842 SOURCE Ignore 3843 NAME Ignore. 3844 VERSION Assume "2.0". 3845 Property Fallback 3846 ATTACH Ignore. 3847 ATTENDEE Required if REQUEST is not implemented; otherwise 3848 ignore. 3849 CATEGORIES Ignore. 3850 CLASS Ignore. 3851 COMMENT Ignore. 3852 COMPLETED Required. 3853 CREATED Ignore. 3854 DAYLIGHT Required if VTIMEZONE is implemented; otherwise 3855 ignore. 3856 DESCRIPTION Required. 3857 DUE Required. 3858 DURATION Ignore. Reply with Not Supported. 3859 DTSTAMP Required. 3860 DTSTART Required. 3861 EXDATE Ignore. Reply with Not Supported. 3862 EXRULE Ignore. Reply with Not Supported. 3863 LAST-MODIFIED Ignore. 3864 LOCATION Ignore. 3865 PERCENT-COMPLETE Ignore 3866 PRIORITY Required. 3867 RELATED-TO Ignore. 3868 RDATE Ignore. If implemented, VTIMEZONE MUST also be 3869 implemented. 3870 RRULE Ignore. The first instance occurs on the DTStart 3871 property. 3872 RESOURCES Ignore. 3873 SEQUENCE Required. 3874 STATUS Required. 3875 SUMMARY Ignore. 3876 TRANSP Required if FREEBUSY is implemented; otherwise Ignore. 3877 TZNAME Required if VTIMEZONE is implemented; otherwise 3878 Ignore. 3879 TZOFFSET Required if VTIMEZONE is implemented; otherwise 3881 Silverberg/Mansour/Dawson/Hopson 76 Expires MAY 1998 3882 Ignore. 3883 URL Ignore. 3884 UID Required. 3885 X- Ignore. 3887 5.1.3 Journal-Related Fallbacks 3889 Method Fallback 3890 -------------- ----------------------------------------------------- 3891 PUBLISH Implementations MAY ignore the profile type. The 3892 REQUEST-STATUS "302;Request not supported" MUST be 3893 returned. 3894 CANCEL Implementations MAY ignore the profile type. The 3895 REQUEST-STATUS "302;Request not supported" MUST be 3896 returned. 3897 REFRESH Implementations MAY ignore the profile type. The 3898 REQUEST-STATUS "302;Request not supported" MUST be 3899 returned. 3901 iCalendar 3902 Property Fallback 3903 -------------- ----------------------------------------------------- 3904 CALSCALE Ignore; assume GREGORIAN. 3905 GEO Ignore. 3906 PRODID Ignore. 3907 METHOD Required as described in the Method list above. 3908 SOURCE Ignore 3909 NAME Ignore. 3910 VERSION Ignore. 3912 Journal-Related 3913 Components Fallback 3914 -------------- ----------------------------------------------------- 3915 VTIMEZONE Required if RRULE or RDATE is implemented; otherwise 3916 ignore and use local time. 3917 CALSCALE Ignore; assume GREGORIAN. 3918 GEO Ignore. 3919 PRODID Ignore. 3920 METHOD Required as described in the Method section above. 3921 SOURCE Ignore 3922 NAME Ignore. 3923 VERSION Assume "2.0". 3925 Component 3926 Property Fallback 3927 -------------- ----------------------------------------------------- 3928 ATTACH Ignore. 3929 ATTENDEE Required if JOURNAL-REQUEST is implemented; otherwise 3930 ignore. 3931 CATEGORIES Ignore. 3932 CLASS Ignore. 3933 COMMENT Ignore. 3935 Silverberg/Mansour/Dawson/Hopson 77 Expires MAY 1998 3936 CREATED Ignore. 3937 DAYLIGHT Required if VTIMEZONE is implemented; otherwise 3938 Ignore. 3939 DESCRIPTION Required. 3940 DTSTAMP Required. 3941 DTSTART Required. 3942 DTEND Required. 3943 EXDATE Ignore. 3944 EXRULE Ignore. 3945 LAST-MODIFIED Ignore. 3946 RELATED-TO Ignore. 3947 RDATE Ignore. If implemented, VTIMEZONE MUST also be 3948 implemented. 3949 RRULE Ignore. The first instance occurs on the DTStart 3950 property. 3951 SEQUENCE Required. 3952 STATUS Ignore. 3953 TRANSP Required if FREEBUSY is implemented; otherwise ignore. 3954 TZNAME Required if VTIMEZONE is implemented; otherwise 3955 ignore. 3956 TZOFFSET Required if VTIMEZONE is implemented; otherwise 3957 ignore. 3958 URL Ignore. 3959 UID Required. 3960 X- Ignore. 3962 5.2 Latency Issues 3964 With a store-and-forward transport, it is possible for events to 3965 arrive out of sequence. That is, you MAY receive a "CANCEL" method 3966 prior to receiving the associated "REQUEST" for the calendar 3967 component. This section discusses a few of these scenarios. 3969 5.2.1 Cancellation of an Unknown Calendar Component. 3971 When a "CANCEL" method is received before the original "REQUEST" 3972 method the calendar will be unable to correlate the "UID" property of 3973 the cancellation with an existing calendar component. It is suggested 3974 that messages that can not be correlated that also contain non-zero 3975 sequence numbers be held and not discarded. Implementations MAY age 3976 them out if no other messages arrive with the same "UID" property 3977 value and a lower sequence number. 3979 5.2.2 Unexpected Reply from an Unknown Delegate 3981 When an "Attendee" delegates an item to another "Calendar User" they 3982 MUST send a "REPLY" method to the "Organizer" using the "ATTENDEE" 3983 properties to indicate the fact that the request was delegated and to 3984 whom the item was delegated. Hence it is possible for an "Organizer" 3985 to receive an "REPLY" from a "Calendar User" not listed as one of the 3987 Silverberg/Mansour/Dawson/Hopson 78 Expires MAY 1998 3988 original "Attendees". The resolution is left to the implementation 3989 but it is expected that the calendaring software will either accept 3990 the reply or hold it until the related "REPLY" method is received 3991 from the "delegator". If the version of the "REPLY" method is out of 3992 date the "Organizer" SHOULD treat the message as a "STATUS-REQUEST" 3993 and update the delegate with the correct version. 3995 5.3 Sequence Number 3997 Under some conditions, a "CUA" MAY receive requests and replies with 3998 the same "SEQUENCE" property value. The "DTSTAMP" property is 3999 utilized as a tie-breaker when two items with the same "SEQUENCE" 4000 property value are evaluated. Furthermore, the "SEQUENCE" property is 4001 only incremented when one or more of the following properties 4002 changes: 4004 . DTSTART 4006 . DTEND 4008 . RDATE 4010 . RRULE 4012 . EXDATE 4014 . EXRULE 4016 . DUE (for VTODO components) 4018 . and possibly LOCATION 4020 6 Security Considerations 4022 This memo outlines an abstract transport protocol which will be bound 4023 to a real-time transport, a store-and-forward transport, and perhaps 4024 other transports. The transport protocol will be responsible for 4025 providing facilities for authentication and encryption using standard 4026 Internet mechanisms that are mutually understood between the sender 4027 and receiver. 4029 6.1 Security Threats 4031 6.1.1 Spoofing the "Organizer" 4033 In this memo, the "Organizer" is the only person authorized to make 4034 changes to an existing "VEVENT", "VTODO", "VJOURNAL" calendar 4035 component and redistribute the updates to the "Attendees". An 4036 iCalendar object that maliciously changes or cancels an existing 4037 "VEVENT", "VTODO" or "VJOURNAL" calendar component MAY be constructed 4038 by someone other than the "Organizer" and sent to the "Attendees". 4040 Silverberg/Mansour/Dawson/Hopson 79 Expires MAY 1998 4041 6.1.2 Spoofing the "Attendee" 4043 In this memo, an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL" 4044 calendar component is the only person authorized to update any 4045 parameter associated with their "ATTENDEE" property and send it to 4046 the "Organizer". An iCalendar object that maliciously changes the 4047 "ATTENDEE" parameters MAY be constructed by someone other than the 4048 real "Attendee" and sent to the "Organizer". 4050 6.1.3 Eavesdropping 4052 The iCalendar object is constructed with human-readable clear text. 4053 Any information contained in an iCalendar object MAY be read and/or 4054 changed by unauthorized persons while the object is in transit. 4056 6.1.4 Flooding a Calendar 4058 Implementations MAY provide a means to automatically incorporate 4059 "REQUEST" methods into a calendar. This presents the opportunity for 4060 a calendar to be flooded with requests, which effectively block all 4061 the calendar's free time. 4063 6.1.5 Procedural Alarms 4065 The "REQUEST" methods for "VEVENT" and "VTODO" calendar components 4066 MAY contain "VALARM" calendar components. The "VALARM" calendar 4067 component MAY be of type PROCEDURE and MAY have an attachment 4068 containing some sort of executable program. Implementations that 4069 incorporate these types of alarms are subject to any virus or 4070 malicious attack that MAY occur as a result of executing the 4071 attachment. 4073 6.2 Recommendations 4075 For an application where the information is sensitive or critical and 4076 the network is subject is subject to a high probability of attack, 4077 iTIP transactions SHOULD be secured. This MAY be accomplished using 4078 public key technology, specifically Security Multiparts for MIME 4079 [RFC1847] in the iTIP transport binding. This helps mitigate the 4080 threats of spoofing, eavesdropping and malicious changes in transit. 4082 6.2.1 Use of [RFC1847] to secure iTIP transactions 4084 iTIP transport bindings SHOULD provide a mechanism based on Security 4085 Multiparts for MIME [RFC1847] to enable authentication of the 4086 sender's identity, and privacy and integrity of the data being 4087 transmitted. This allows the receiver of a signed iCalendar object to 4088 verify the identity of the sender. This sender MAY then be correlated 4090 Silverberg/Mansour/Dawson/Hopson 80 Expires MAY 1998 4091 to an "ATTENDEE" property in the iCalendar object. If the correlation 4092 is made and the sender is authorized to make the requested change or 4093 update then the operation MAY proceed. It also allows the message to 4094 be encrypted to prevent unauthorized reading of the message contents 4095 in transit. iTIP transport binding documents describe this process in 4096 detail. 4098 6.2.2 Implementation Controls 4100 The threat of flooding a calendar SHOULD be mitigated by a calendar 4101 system that uses this protocol by providing controls that MAY be used 4102 to limit the acceptable sources for iTIP transactions, and perhaps 4103 the size of messages and volume of traffic, by source. 4105 The threat of malicious procedural alarms SHOULD be mitigated by a 4106 calendar system that uses this protocol by providing controls that 4107 MAY be used to disallow procedural alarms in iTIP transactions and/or 4108 remove all alarms from the object before delivery to the recipient. 4110 7 Acknowledgments 4112 A hearty thanks to the following individuals who have participated in 4113 the drafting, review and discussion of this memo: 4115 Anik Ganguly, Bruce Kahn, John Noerenberg, Leo Parker, John Rose, 4116 Vinod Seraphin, Richard Shusterman, Derik Stenerson, John Sun, Kevin 4117 Tsurutome. 4119 8 Bibliography 4121 [ICAL] "Internet Calendaring and Scheduling Core Object Specification 4122 - iCalendar", Internet-Draft, October 1997, 4123 ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-03.txt. 4125 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, 4126 October 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch- 4127 mod-01.txt. 4129 [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", 4130 Internet-Draft, July 1996, ftp://ftp.ietf.org/internet-drafts/draft- 4131 yergeau-utf8-01.txt. 4133 [IMIP] "iCalendar Message-Based Interoperability Protocol - iMIP", 4134 Internet-Draft, October 1997, ftp://ftp.ietf.org/internet- 4135 drafts/draft-ietf-calsch-imip-01.txt. 4137 [ISO8601] "Data elements and interchange formats - information 4138 interchange - Representation of dates and times", ISO 8601, 1996-06- 4139 15, +1 (212) 642-4900 for ANSI Sales. 4141 [VCAL] "vCalendar - The Electronic Calendaring and Scheduling Format 4142 - Version 1.0", Versit Consortium, September 18, 1996, 4143 http://www.imc.org/pdi/vcal-10.doc. 4145 Silverberg/Mansour/Dawson/Hopson 81 Expires MAY 1998 4147 [VCARD] "vCard - The Electronic Business Card Exchange Format - 4148 Version 2.1", Versit Consortium, September 18, 1996, 4149 http://www.imc.org/pdi/vcard-21.doc. 4151 [RFC821] Postel, "Simple Mail Transfer Protocol", RFC 821, 4152 organization name, November 1996, 4153 http://ds.internic.net/rfc/rfc821.txt. 4155 [RFC1983] "Internet Users' Glossary", RFC 1983, August 1996, 4156 http://ds.internic.net/rfc/rfc1983.txt. 4158 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 4159 RFC 2119, March 1997, http://ds.internic.net/rfc/rfc2119.txt. 4161 [RFC2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail 4162 Extensions - Part One - Format of Internet Message Bodies", RFC 2045, 4163 Innosoft, First Virtual, November 1996, 4164 http://ds.internic.net/rfc/rfc2045.txt. 4166 [RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail 4167 Extensions - Part Two - Media Types", RFC 2046, Innosoft, First 4168 Virtual, November 1996, http://ds.internic.net/rfc/rfc2046.txt. 4170 [UNICODE] The Unicode Consortium, "The Unicode Standard -Version 4171 2.0", Addison-Wesley Developers Press, July 1996. UTF-8 is described 4172 in section A-2. 4174 [US-ASCII] Coded Character Set--7-bit AmeriMAYStandard Code for 4175 Information Interchange, ANSI X3.4-1986. 4177 9 Authors Addresses 4179 The following address information is provided in a MIME-VCARD, 4180 Electronic Business Card, format. 4182 The authors of this draft are: 4184 BEGIN:VCARD 4185 FN:Frank Dawson 4186 ORG:Lotus Development Corporation 4187 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- 4188 3502;USA 4189 TEL;WORK;MSG:+1-919-676-9515 4190 TEL;WORK;FAX:+1-919-676-9564 4191 EMAIL;INTERNET:Frank_Dawson@Lotus.com 4192 URL:http://home.earthlink.net/~fdawson 4193 END:VCARD 4195 BEGIN:VCARD 4196 FN:Ross Hopson 4197 ORG:On Technology, Inc. 4198 ADR;WORK;POSTAL;PARCEL:Suite 1600;;434 Fayetteville St. 4199 Mall, Two Hannover Square;Raleigh;NC;27601 4200 TEL;WORK;MSG:+1-919-890-4036 4202 Silverberg/Mansour/Dawson/Hopson 82 Expires MAY 1998 4203 TEL;WORK;FAX:+1-919-890-4100 4204 EMAIL;INTERNET:rhopson@on.com 4205 END:VCARD 4207 BEGIN:VCARD 4208 FN:Steve Mansour 4209 ORG:Netscape Communications Corporation 4210 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 4211 View;CA;94043;USA 4212 TEL;WORK;MSG:+1-415-937-2378 4213 TEL;WORK;FAX:+1-415-428-4059 4214 EMAIL;INTERNET:sman@netscape.com 4215 END:VCARD 4217 BEGIN:VCARD 4218 FN:Steve Silverberg 4219 ORG:Microsoft Corporation 4220 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 4221 Redmond;WA;98052-6399;USA 4222 TEL;WORK;MSG:+1-425-936-9277 4223 TEL;WORK;FAX:+1-425-936-8019 4224 EMAIL;INTERNET:stevesil@Microsoft.com 4225 END:VCARD 4227 The iCalendar object is a result of the work of the Internet 4228 Engineering Task Force Calendaring and scheduling Working Group. The 4229 chairman of that working group is: 4231 BEGIN:VCARD 4232 FN:Anik Ganguly 4233 ORG:Campbel Services, Inc. 4234 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern 4235 Highway;Southfield;MI;48075;USA 4236 TEL;WORK;MSG:+1-248-559-5955 4237 TEL;WORK;FAX:+1-248-559-5034 4238 EMAIL;INTERNET:anik@ontime.com 4239 END:VCARD 4241 10 Full Copyright Statement 4243 "Copyright (C) The Internet Society (date). All Rights Reserved. 4245 This document and translations of it MAY be copied and furnished to 4246 others, and derivative works that comment on or otherwise explain it 4247 or assist in its implmentation MAY be prepared, copied, published and 4248 distributed, in whole or in part, without restriction of any kind, 4249 provided that the above copyright notice and this paragraph are 4250 included on all such copies and derivative works. However, this 4251 document itself MAY NOT be modified in any way, such as by removing 4252 the copyright notice or references to the Internet Society or other 4253 Internet organizations, except as needed for the purpose of 4254 developing Internet standards in which case the procedures for 4256 Silverberg/Mansour/Dawson/Hopson 83 Expires MAY 1998 4257 copyrights defined in the Internet Standards process MUST be 4258 followed, or as required to translate it into languages other than 4259 English. 4261 The limited permissions granted above are perpetual and will not be 4262 revoked by the Internet Society or its successors or assigns. 4264 This document and the information contained herein is provided on an 4265 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4266 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4267 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4268 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4269 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4271 Silverberg/Mansour/Dawson/Hopson 84 Expires MAY 1998