draft-ietf-calsch-itip-03.txt   draft-ietf-calsch-itip-04.txt 
Network Working Group Steve Silverberg, Microsoft Network Working Group Steve Silverberg, Microsoft
INTERNET-DRAFT Steve Mansour, Netscape INTERNET-DRAFT Steve Mansour, Netscape
Calendaring and Scheduling Working Group Frank Dawson, Lotus Calendaring and Scheduling Working Group Frank Dawson, Lotus
<ietf-draft-calsch-itip-03.txt Ross Hopson, ON Technologies <draft-ietf-calsch-itip-04.txt Ross Hopson, ON Technologies
Expires in six months from March 13, 1998 Expires six months after: May 11, 1998
iCalendar Transport-Independent Interoperability Protocol iCalendar Transport-Independent Interoperability Protocol
(iTIP) (iTIP)
Scheduling Events, BusyTime, To-dos and Journal Entries Scheduling Events, BusyTime, To-dos and Journal Entries
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts are draft documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or made obsolete by other Internet-Drafts may be updated, replaced, or made obsolete by other
documents at any time. It is not appropriate to use Internet-Drafts as documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or reference material or to cite them other than as a "working draft" or
"work in progress". "work in progress".
To learn the current status of any Internet-Draft, please check the 1id- To view the entire list of current Internet-Drafts, please check
abstracts.txt listing contained in the Internet-Drafts Shadow the "1id-abstracts.txt" listing contained in the Internet-Drafts
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Copyright (C) The Internet Society 1997. All Rights Reserved. Copyright (C) The Internet Society 1997. All Rights Reserved.
Abstract Abstract
This document specifies how calendaring systems use iCalendar objects to This document specifies how calendaring systems use iCalendar objects to
interoperate with other calendar systems. It does so in a general way so interoperate with other calendar systems. It does so in a general way so
as to allow multiple methods of communication between systems. as to allow multiple methods of communication between systems.
Subsequent documents specify interoperable methods of communications Subsequent documents specify interoperable methods of communications
between systems that use this protocol. between systems that use this protocol.
The document outlines a model for calendar exchange that defines both The document outlines a model for calendar exchange that defines both
static and dynamic event, to-do, journal and free/busy objects. Static static and dynamic event, to-do, journal and free/busy objects. Static
objects are used to transmit information from one entity to another objects are used to transmit information from one entity to another
without the expectation of continuity or referential integrity with the without the expectation of continuity or referential integrity with the
original item. Dynamic objects are a superset of static objects and will original item. Dynamic objects are a superset of static objects and will
gracefully degrade to their static counterparts for clients that only gracefully degrade to their static counterparts for clients that only
support static objects. support static objects.
Silverberg/Mansour/Dawson/Hopson 1 Expires September 1998 This document specifies an Internet protocol based on the iCalendar
object specification that provides scheduling interoperability between
different calendar systems. The Internet protocol is called the
'iCalendar Transport-Independent Interoperability Protocol (iTIP)'.
Silverberg/Mansour/Dawson/Hopson 2 Expires September 1998 iTIP complements the iCalendar object specification by adding semantics
for group scheduling methods commonly available in current calendar
systems. These scheduling methods permit two or more calendar systems to
perform transactions such as publish, schedule, reschedule, respond to
Silverberg/Mansour/Dawson/Hopson 3 Expires September 1998 Silverberg/Mansour/Daws/Hopson 1 Expires November 1998
scheduling requests, negotiation of changes or cancel iCalendar-based
calendar components.
iTIP is defined independent of the particular transport used to transmit
the scheduling information. Companion memos to iTIP provide bindings of
the interoperability protocol to a number of Internet protocols.
Silverberg/Mansour/Daws/Hopson 2 Expires November 1998
Table of Contents Table of Contents
1 INTRODUCTION.........................................................9 1 INTRODUCTION.........................................................6
1.1 FORMATTING CONVENTIONS ...........................................9 1.1 FORMATTING CONVENTIONS ...........................................6
1.2 RELATED DOCUMENTS ...............................................10 1.2 RELATED DOCUMENTS ................................................7
1.3 ITIP ROLES AND TRANSACTIONS .....................................10 1.3 ITIP ROLES AND TRANSACTIONS ......................................7
2 INTEROPERABILITY MODELS.............................................11 2 INTEROPERABILITY MODELS..............................................9
2.1 APPLICATION PROTOCOL ............................................12 2.1 APPLICATION PROTOCOL .............................................9
2.1.1 Calendar Entry State ........................................12 2.1.1 Calendar Entry State ........................................10
2.1.2 Delegation ..................................................13 2.1.2 Delegation ..................................................10
2.1.3 Acting on Behalf of other Calendar Users ....................13 2.1.3 Acting on Behalf of other Calendar Users ....................10
2.1.4 Component Revisions .........................................10
2.1.5 Message Sequencing ..........................................11
3 APPLICATION PROTOCOL ELEMENTS.......................................13 3 APPLICATION PROTOCOL ELEMENTS.......................................12
3.1 COMMON COMPONENT RESTRICTION TABLES .............................14 3.1 COMMON COMPONENT RESTRICTION TABLES .............................13
3.2 METHODS FOR VEVENT CALENDAR COMPONENTS ..........................15 3.2 METHODS FOR VEVENT CALENDAR COMPONENTS ..........................14
3.2.1 PUBLISH .....................................................16 3.2.1 PUBLISH .....................................................15
3.2.2 REQUEST .....................................................17 3.2.2 REQUEST .....................................................16
3.2.2.1 Rescheduling an Event....................................18 3.2.2.1 Rescheduling an Event....................................18
3.2.2.2 Updating or Reconfirmation of an Event...................19 3.2.2.2 Updating or Reconfirmation of an Event...................18
3.2.2.3 Delegating an Event to another CU........................19 3.2.2.3 Delegating an Event to another CU........................18
3.2.2.4 Changing the Organizer...................................20 3.2.2.4 Changing the Organizer...................................19
3.2.2.5 Sending on Behalf of the Organizer.......................20 3.2.2.5 Sending on Behalf of the Organizer.......................19
3.2.2.6 Forwarding to An Uninvited CU............................20 3.2.2.6 Forwarding to An Uninvited CU............................19
3.2.2.7 Updating Attendee Status.................................20 3.2.2.7 Updating Attendee Status.................................20
3.2.3 REPLY .......................................................20 3.2.3 REPLY .......................................................20
3.2.4 ADD .........................................................22 3.2.4 ADD .........................................................22
3.2.5 CANCEL ......................................................23 3.2.5 CANCEL ......................................................23
3.2.6 REFRESH .....................................................25 3.2.6 REFRESH .....................................................25
3.2.7 COUNTER .....................................................26 3.2.7 COUNTER .....................................................26
3.2.8 DECLINECOUNTER ..............................................28 3.2.8 DECLINECOUNTER ..............................................27
3.3 METHODS FOR VFREEBUSY COMPONENTS ................................29 3.3 METHODS FOR VFREEBUSY COMPONENTS ................................28
3.3.1 PUBLISH .....................................................30 3.3.1 PUBLISH .....................................................29
3.3.2 REQUEST .....................................................31 3.3.2 REQUEST .....................................................30
3.3.3 REPLY .......................................................32 3.3.3 REPLY .......................................................31
3.4 METHODS FOR VTODO COMPONENTS ....................................34 3.4 METHODS FOR VTODO COMPONENTS ....................................32
3.4.1 PUBLISH .....................................................35 3.4.1 PUBLISH .....................................................33
3.4.2 REQUEST .....................................................36 3.4.2 REQUEST .....................................................34
3.4.2.1 REQUEST for Rescheduling a VTODO.........................37 3.4.2.1 REQUEST for Rescheduling a VTODO.........................36
3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO..........38 3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO..........36
3.4.2.3 REQUEST for Delegating a VTODO...........................38 3.4.2.3 REQUEST for Delegating a VTODO...........................37
3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User..........39 3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User..........37
3.4.2.5 REQUEST Updated Attendee Status..........................39 3.4.2.5 REQUEST Updated Attendee Status..........................38
3.4.3 REPLY .......................................................39 3.4.3 REPLY .......................................................38
3.4.4 ADD .........................................................41 3.4.4 ADD .........................................................39
3.4.5 CANCEL ......................................................42 3.4.5 CANCEL ......................................................41
3.4.6 REFRESH .....................................................43
3.4.7 COUNTER .....................................................45
3.4.8 DECLINECOUNTER ..............................................46
3.5 METHODS FOR VJOURNAL COMPONENTS .................................47
Silverberg/Mansour/Dawson/Hopson 4 Expires September 1998 Silverberg/Mansour/Daws/Hopson 3 Expires November 1998
3.4.6 REFRESH .....................................................42
3.4.7 COUNTER .....................................................44
3.4.8 DECLINECOUNTER ..............................................45
3.5 METHODS FOR VJOURNAL COMPONENTS .................................46
3.5.1 PUBLISH .....................................................47 3.5.1 PUBLISH .....................................................47
3.5.2 ADD .........................................................49 3.5.2 ADD .........................................................48
3.5.3 CANCEL ......................................................50 3.5.3 CANCEL ......................................................49
3.6 STATUS REPLIES ..................................................51 3.6 STATUS REPLIES ..................................................50
3.7 IMPLEMENTATION CONSIDERATIONS ...................................53 3.7 IMPLEMENTATION CONSIDERATIONS ...................................52
3.7.1 Working With Recurrence Instances ...........................53 3.7.1 Working With Recurrence Instances ...........................52
3.7.2 Attendee Property Considerations ............................54 3.7.2 Attendee Property Considerations ............................53
3.7.3 X-Tokens ....................................................55 3.7.3 X-Tokens ....................................................54
4 EXAMPLES............................................................55 4 EXAMPLES............................................................54
4.1 PUBLISHED EVENT EXAMPLES ........................................55 4.1 PUBLISHED EVENT EXAMPLES ........................................54
4.1.1 A Minimal Published Event ...................................56 4.1.1 A Minimal Published Event ...................................55
4.1.2 Changing A Published Event ..................................56 4.1.2 Changing A Published Event ..................................55
4.1.3 Canceling A Published Event .................................57 4.1.3 Canceling A Published Event .................................56
4.1.4 A Rich Published Event ......................................57 4.1.4 A Rich Published Event ......................................56
4.1.5 Anniversaries or Events attached to entire days .............58 4.1.5 Anniversaries or Events attached to entire days .............57
4.2 GROUP EVENT EXAMPLES ............................................59 4.2 GROUP EVENT EXAMPLES ............................................58
4.2.1 A Group Event Request .......................................60 4.2.1 A Group Event Request .......................................58
4.2.2 Reply To A Group Event Request ..............................60 4.2.2 Reply To A Group Event Request ..............................59
4.2.3 Update An Event .............................................61 4.2.3 Update An Event .............................................60
4.2.4 Countering an Event Proposal ................................61 4.2.4 Countering an Event Proposal ................................60
4.2.5 Delegating an Event .........................................63 4.2.5 Delegating an Event .........................................62
4.2.6 Delegate Accepts the Meeting ................................65 4.2.6 Delegate Accepts the Meeting ................................64
4.2.7 Delegate Declines the Meeting ...............................66 4.2.7 Delegate Declines the Meeting ...............................65
4.2.8 Forwarding an Event Request .................................67 4.2.8 Forwarding an Event Request .................................66
4.2.9 Cancel A Group Event ........................................67 4.2.9 Cancel A Group Event ........................................66
4.2.10 Removing Attendees .........................................68 4.2.10 Removing Attendees .........................................67
4.2.11 Replacing the Organizer ....................................69 4.2.11 Replacing the Organizer ....................................68
4.3 BUSY TIME EXAMPLES ..............................................70 4.3 BUSY TIME EXAMPLES ..............................................69
4.3.1 Request Busy Time ...........................................70 4.3.1 Request Busy Time ...........................................70
4.3.2 Reply To A Busy Time Request ................................71 4.3.2 Reply To A Busy Time Request ................................70
4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ..........................71 4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ..........................70
4.4.1 A Recurring Event Spanning Time Zones .......................71 4.4.1 A Recurring Event Spanning Time Zones .......................70
4.4.2 Modify A Recurring Instance .................................73 4.4.2 Modify A Recurring Instance .................................72
4.4.3 Cancel an Instance ..........................................74 4.4.3 Cancel an Instance ..........................................73
4.4.4 Cancel Recurring Event ......................................75 4.4.4 Cancel Recurring Event ......................................74
4.4.5 Change All Future Instances .................................75 4.4.5 Change All Future Instances .................................74
4.4.6 Add A New Instance To A Recurring Event .....................75 4.4.6 Add A New Instance To A Recurring Event .....................75
4.4.7 Add A New Series of Instances To A Recurring Event ..........76 4.4.7 Add A New Series of Instances To A Recurring Event ..........75
4.4.8 Counter An Instance Of A Recurring Event ....................80 4.4.8 Counter An Instance Of A Recurring Event ....................79
4.4.9 Error Reply To A Request ....................................80 4.4.9 Error Reply To A Request ....................................79
4.5 GROUP TO-DO EXAMPLES ............................................81 4.5 GROUP TO-DO EXAMPLES ............................................80
4.5.1 A VTODO Request .............................................82 4.5.1 A VTODO Request .............................................81
4.5.2 A VTODO Reply ...............................................83 4.5.2 A VTODO Reply ...............................................82
4.5.3 A VTODO Request for Updated Status ..........................83 4.5.3 A VTODO Request for Updated Status ..........................82
4.5.4 A Reply: Percent-Complete ...................................84 4.5.4 A Reply: Percent-Complete ...................................83
4.5.5 A Reply: Completed ..........................................84 4.5.5 A Reply: Completed ..........................................83
4.5.6 An Updated VTODO Request ....................................84 4.5.6 An Updated VTODO Request ....................................83
4.5.7 Recurring VTODOs ............................................85 4.5.7 Recurring VTODOs ............................................84
4.5.7.1 Request for a Recurring VTODO............................85
4.5.7.2 Calculating due dates in recurring VTODOs................85
4.5.7.3 Replying to an instance of a recurring VTODO.............86
4.6 JOURNAL EXAMPLES ................................................86
Silverberg/Mansour/Dawson/Hopson 5 Expires September 1998 Silverberg/Mansour/Daws/Hopson 4 Expires November 1998
4.7 OTHER EXAMPLES ..................................................87 4.5.7.1 Request for a Recurring VTODO............................84
4.7.1 Event Refresh ...............................................87 4.5.7.2 Calculating due dates in recurring VTODOs................85
4.7.2 Bad RECURRENCE-ID ...........................................87 4.5.7.3 Replying to an instance of a recurring VTODO.............85
4.6 JOURNAL EXAMPLES ................................................85
4.7 OTHER EXAMPLES ..................................................86
4.7.1 Event Refresh ...............................................86
4.7.2 Bad RECURRENCE-ID ...........................................86
5 APPLICATION PROTOCOL FALLBACKS......................................88 5 APPLICATION PROTOCOL FALLBACKS......................................88
5.1 PARTIAL IMPLEMENTATION ..........................................88 5.1 PARTIAL IMPLEMENTATION ..........................................88
5.1.1 Event-Related Fallbacks .....................................89 5.1.1 Event-Related Fallbacks .....................................88
5.1.2 To-Do-Related Fallbacks .....................................90 5.1.2 Free/Busy-Related Fallbacks .................................90
5.1.3 Journal-Related Fallbacks ...................................92 5.1.3 To-Do-Related Fallbacks .....................................90
5.1.4 Journal-Related Fallbacks ...................................92
5.2 LATENCY ISSUES ..................................................93 5.2 LATENCY ISSUES ..................................................93
5.2.1 Cancellation of an Unknown Calendar Component. ..............93 5.2.1 Cancellation of an Unknown Calendar Component. ..............93
5.2.2 Unexpected Reply from an Unknown Delegate ...................93 5.2.2 Unexpected Reply from an Unknown Delegate ...................93
5.3 SEQUENCE NUMBER .................................................94 5.3 SEQUENCE NUMBER .................................................93
6 SECURITY CONSIDERATIONS.............................................94 6 SECURITY CONSIDERATIONS.............................................94
6.1 SECURITY THREATS ................................................94 6.1 SECURITY THREATS ................................................94
6.1.1 Spoofing the "Organizer" ....................................94 6.1.1 Spoofing the "Organizer" ....................................94
6.1.2 Spoofing the "Attendee" .....................................94 6.1.2 Spoofing the "Attendee" .....................................94
6.1.3 Unauthorized Replacement of the Organizer ...................95 6.1.3 Unauthorized Replacement of the Organizer ...................94
6.1.4 Eavesdropping ...............................................95 6.1.4 Eavesdropping ...............................................94
6.1.5 Flooding a Calendar .........................................95 6.1.5 Flooding a Calendar .........................................95
6.1.6 Procedural Alarms ...........................................95 6.1.6 Procedural Alarms ...........................................95
6.1.7 Unauthorized REFRESH Requests ...............................95 6.1.7 Unauthorized REFRESH Requests ...............................95
6.2 RECOMMENDATIONS .................................................95 6.2 RECOMMENDATIONS .................................................95
6.2.1 Use of [RFC1847] to secure iTIP transactions ................96 6.2.1 Use of [RFC-1847] to secure iTIP transactions ...............95
6.2.2 Implementation Controls .....................................96 6.2.2 Implementation Controls .....................................96
7 ACKNOWLEDGMENTS.....................................................96 7 ACKNOWLEDGMENTS.....................................................96
8 BIBLIOGRAPHY........................................................97 8 BIBLIOGRAPHY........................................................96
9 AUTHORS ADDRESSES...................................................98 9 AUTHORS ADDRESSES...................................................97
10 FULL COPYRIGHT STATEMENT...........................................99 10 FULL COPYRIGHT STATEMENT...........................................99
Silverberg/Mansour/Dawson/Hopson 6 Expires September 1998 Silverberg/Mansour/Daws/Hopson 5 Expires November 1998
1 Introduction 1 Introduction
This document specifies how calendaring systems use iCalendar objects to This document specifies how calendaring systems use iCalendar objects to
interoperate with other calendar systems. In particular, it specifies interoperate with other calendar systems. In particular, it specifies
how to schedule events, to-dos, or daily journal entries. It further how to schedule events, to-dos, or daily journal entries. It further
specifies how to search for available busy time information. It does so specifies how to search for available busy time information. It does so
in a general way so as to allow multiple methods of communication in a general way so as to allow multiple methods of communication
between systems. Subsequent documents specify transport bindings between between systems. Subsequent documents specify transport bindings between
systems that use this protocol. systems that use this protocol.
skipping to change at line 226 skipping to change at line 243
in order to update their status and may also return transaction/request in order to update their status and may also return transaction/request
status information. The protocol supports the ability for the message status information. The protocol supports the ability for the message
originator to modify or cancel the original message. The protocol also originator to modify or cancel the original message. The protocol also
supports the ability for recipients to suggest changes to the originator supports the ability for recipients to suggest changes to the originator
of a message. The elements of the protocol also define the user roles of a message. The elements of the protocol also define the user roles
for its transactions. for its transactions.
1.1 Formatting Conventions 1.1 Formatting Conventions
In order to refer to elements of the calendaring and scheduling model, In order to refer to elements of the calendaring and scheduling model,
core object or interoperability protocol defined in [ICMS], [ICAL] and core object or interoperability protocol defined in [ICMS], [iCAL] and
[ITIP] several formatting conventions have been utilized. [iTIP] several formatting conventions have been utilized.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC-2119].
Calendaring and scheduling roles described by [ICMS] are referred to in Calendaring and scheduling roles described by [ICMS] are referred to in
quoted-strings of text with the first character of each word in upper quoted-strings of text with the first character of each word in upper
case. For example, "Organizer" refers to a role of a "Calendar User" case. For example, "Organizer" refers to a role of a "Calendar User"
(CU) within the scheduling protocol defined by [ITIP]. Calendar (CU) within the scheduling protocol defined by [iTIP]. Calendar
components defined by [ICAL] are referred to with capitalized, quoted- components defined by [iCAL] are referred to with capitalized, quoted-
strings of text. All calendar components start with the letter "V". For strings of text. All calendar components start with the letter "V". For
example, "VEVENT" refers to the event calendar component, "VTODO" refers example, "VEVENT" refers to the event calendar component, "VTODO" refers
to the to-do calendar component and "VJOURNAL" refers to the daily to the to-do calendar component and "VJOURNAL" refers to the daily
journal calendar component. Scheduling methods defined by [ITIP] are journal calendar component. Scheduling methods defined by [iTIP] are
referred to with capitalized, quoted-strings of text. For example, referred to with capitalized, quoted-strings of text. For example,
"REQUEST" refers to the method for requesting a scheduling calendar "REQUEST" refers to the method for requesting a scheduling calendar
component be created or modified, "REPLY" refers to the method a component be created or modified, "REPLY" refers to the method a
recipient of a request uses to update their status with the "Organizer" recipient of a request uses to update their status with the "Organizer"
of the calendar component. of the calendar component.
Properties defined by [ICAL] are referred to with capitalized, quoted- Properties defined by [iCAL] are referred to with capitalized, quoted-
strings of text, followed by the word "property". For example, strings of text, followed by the word "property". For example,
"ATTENDEE" property refers to the iCalendar property used to convey the "ATTENDEE" property refers to the iCalendar property used to convey the
calendar address of a "Calendar User". Property parameters defined by calendar address of a "Calendar User". Property parameters defined by
this memo are referred to with lower case, quoted-strings of text, this memo are referred to with lower case, quoted-strings of text,
followed by the word "parameter". For example, "value" parameter refers followed by the word "parameter". For example, "value" parameter refers
to the iCalendar property parameter used to override the default data to the iCalendar property parameter used to override the default data
Silverberg/Mansour/Dawson/Hopson 7 Expires September 1998 Silverberg/Mansour/Daws/Hopson 6 Expires November 1998
type for a property value. Enumerated values defined by this memo are type for a property value. Enumerated values defined by this memo are
referred to with capitalized text, either alone or followed by the word referred to with capitalized text, either alone or followed by the word
"value". "value".
In tables, the quoted-string text is specified without quotes in order In tables, the quoted-string text is specified without quotes in order
to minimize the table length. to minimize the table length.
1.2 Related Documents 1.2 Related Documents
Implementers will need to be familiar with several other memos that, Implementers will need to be familiar with several other memos that,
along with this one, describe the Internet calendaring and scheduling along with this one, describe the Internet calendaring and scheduling
standards. This document, [ITIP], specifies an interoperability protocol standards. This document, [iTIP], specifies an interoperability protocol
for scheduling between different implementations. The related documents for scheduling between different implementations. The related documents
are: are:
[ICMS] - describes the abstract model and defines common terms and [ICMS] - describes the abstract model and defines common terms and
concepts; concepts;
[ICAL] - specifies the objects, data types, properties and property [iCAL] - specifies the objects, data types, properties and property
parameters used in the protocols, along with the methods for parameters used in the protocols, along with the methods for
representing and encoding them; representing and encoding them;
[IRIP] - specifies an Internet real time protocol binding for [iMIP] specifies an Internet email binding for [iTIP].
[ITIP];
[IMIP] specifies an Internet email binding for [ITIP].
This memo does not attempt to repeat the specification of concepts or This memo does not attempt to repeat the specification of concepts or
definitions from these other memos. Where possible, references are made definitions from these other memos. Where possible, references are made
to the memo that provides for the specification of these concepts or to the memo that provides for the specification of these concepts or
definitions. definitions.
1.3 ITIP Roles and Transactions 1.3 ITIP Roles and Transactions
ITIP defines seven methods for exchanging [ICAL] objects for the ITIP defines methods for exchanging [iCAL] objects for the purposes of
purposes of group calendaring and scheduling between "Calendar Users" group calendaring and scheduling between "Calendar Users" (CUs). CUs
(CUs). CUs take on one of two roles in iTIP. The CU who initiates an take on one of two roles in iTIP. The CU who initiates an exchange takes
exchange takes on the role of "Organizer". For example, the CU who on the role of "Organizer". For example, the CU who proposes a group
proposes a group meeting is the "Organizer". The CUs asked to meeting is the "Organizer". The CUs asked to participate in the group
participate in the group meeting by the "Organizer" take on the role of meeting by the "Organizer" take on the role of "Attendee". Note that
"Attendee". Note that "role" is also a descriptive parameter to the "role" is also a descriptive parameter to the _ATTENDEE_ property. Its
_ATTENDEE_ property. Its use is to convey descriptive context to an use is to convey descriptive context to an "Attendee" such as "chair",
"Attendee" such as "chair", "req-participant" or "non-participant" and "req-participant" or "non-participant" and has nothing to do with the
has nothing to do with the calendaring workflow. calendaring workflow.
The ITIP methods are defined below and their usage and semantics are The ITIP methods are listed below and their usage and semantics are
outlined in section 3 of this document. defined in section 3 of this document.
+================+==================================================+ +================+==================================================+
| Method | Description | | Method | Description |
|================+==================================================| |================+==================================================|
| PUBLISH | Used to publish a calendar entry to one or more | | PUBLISH | Used to publish a calendar entry to one or more |
Silverberg/Mansour/Dawson/Hopson 8 Expires September 1998
| | Calendar Users. There is no interactivity | | | Calendar Users. There is no interactivity |
| | between the publisher and any other calendar | | | between the publisher and any other calendar |
| | user. An example might include a baseball team | | | user. An example might include a baseball team |
Silverberg/Mansour/Daws/Hopson 7 Expires November 1998
| | publishing its schedule to the public. | | | publishing its schedule to the public. |
| | | | | |
| REQUEST | Used to schedule a calendar entry with other | | REQUEST | Used to schedule a calendar entry with other |
| | Calendar Users. Requests are interactive in that | | | Calendar Users. Requests are interactive in that |
| | they require the receiver to respond using | | | they require the receiver to respond using |
| | the the Reply methods. Meeting Requests, Busy | | | the the Reply methods. Meeting Requests, Busy |
| | Time requests and the assignment of VTODOs to | | | Time requests and the assignment of VTODOs to |
| | other Calendar Users are all examples. | | | other Calendar Users are all examples. |
| | Requests are also used by the "Organizer" to | | | Requests are also used by the "Organizer" to |
| | update the status of a calendar entry. | | | update the status of a calendar entry. |
skipping to change at line 351 skipping to change at line 363
| COUNTER | The Counter method is used by an "Attendee" to | | COUNTER | The Counter method is used by an "Attendee" to |
| | negotiate a change in the calendar entry. | | | negotiate a change in the calendar entry. |
| | Examples include the request to change a | | | Examples include the request to change a |
| | proposed Event time or change the due date for a | | | proposed Event time or change the due date for a |
| | VTODO. | | | VTODO. |
| | | | | |
| DECLINE- | Used by the "Organizer" to decline the proposed | | DECLINE- | Used by the "Organizer" to decline the proposed |
| COUNTER | counter-proprosal. | | COUNTER | counter-proprosal. |
+================+==================================================+ +================+==================================================+
Group scheduling in iTIP is accomplished using the set of "request" and
"response" methods described above. The following table shows the
methods broken down by who can send them.
+================+==================================================+
| Originator | Methods |
|================+==================================================|
| Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER |
| | |
| Attendee | REPLY, REFRESH, COUNTER |
| | REQUEST only when delegating |
+================+==================================================+
Note that for some calendar component types, the allowable methods are a
subset of the above set.
Silverberg/Mansour/Daws/Hopson 8 Expires November 1998
2 Interoperability Models 2 Interoperability Models
There are two distinct protocols relevant to interoperability: an There are two distinct protocols relevant to interoperability: an
"Application Protocol" and a "Transport Protocol". The Application "Application Protocol" and a "Transport Protocol". The Application
Protocol defines the content of the iCalendar objects sent between Protocol defines the content of the iCalendar objects sent between
sender and receiver to accomplish the scheduling transactions described sender and receiver to accomplish the scheduling transactions listed
above. The Transport Protocol defines how the iCalendar objects are sent above. The Transport Protocol defines how the iCalendar objects are sent
between the sender and receiver. This document focuses on the between the sender and receiver. This document focuses on the
Application Protocol. Binding documents such as [IMIP] and [IRIP] focus Application Protocol. Binding documents such as [iMIP] focus on the
on the Transport Protocol. Transport Protocol.
The connection between Sender and Receiver in the diagram below refers The connection between Sender and Receiver in the diagram below refers
to the Application Protocol. The iCalendar objects passed from the to the Application Protocol. The iCalendar objects passed from the
Sender to the Receiver are presented in Section 3, Application Protocol Sender to the Receiver are presented in Section 3, Application Protocol
Elements. Elements.
Silverberg/Mansour/Dawson/Hopson 9 Expires September 1998
+----------+ +----------+ +----------+ +----------+
| | iTIP | | | | iTIP | |
| Sender |<-------------------->| Receiver | | Sender |<-------------------->| Receiver |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
There are several variations of this diagram in which the Sender and There are several variations of this diagram in which the Sender and
Receiver take on various roles of a "Calendar User Agent" (CUA) or a Receiver take on various roles of a "Calendar User Agent" (CUA) or a
"Calendar Service" (CS). These variants are detailed in the Model "Calendar Service" (CS). These variants are detailed in the Model
document [ICMS]. document [ICMS].
skipping to change at line 394 skipping to change at line 421
+------------------------------------------+ +------------------------------------------+
| iTIP | | iTIP |
+------------------------------------------+ +------------------------------------------+
|Real-time | Store-and-Fwd | Other | |Real-time | Store-and-Fwd | Other |
|Transport | Transport | Transports... | |Transport | Transport | Transports... |
+------------------------------------------+ +------------------------------------------+
2.1 Application Protocol 2.1 Application Protocol
The iTIP model is in which a calendar entry is created and managed by an In the iTIP model, a calendar entry is created and managed by an
"Organizer". The "Organizer" interacts with other CUs by sending one or "Organizer". The "Organizer" interacts with other CUs by sending one or
more of the iTIP messages described above. "Attendees" use the "REPLY" more of the iTIP messages listed above. "Attendees" use the "REPLY"
method to communicate their status. "Attendees" do not make direct method to communicate their status. "Attendees" do not make direct
changes to the master calendar entry. They can, however, use the changes to the master calendar entry. They can, however, use the
"COUNTER" method to suggest changes to the "Organizer". The "Organizer" "COUNTER" method to suggest changes to the "Organizer". In any case, the
has complete control over the master calendar entry. "Organizer" has complete control over the master calendar entry.
Silverberg/Mansour/Daws/Hopson 9 Expires November 1998
2.1.1 Calendar Entry State 2.1.1 Calendar Entry State
There are two distinct states relevant to calendar entries: the overall There are two distinct states relevant to calendar entries: the overall
state of the entry and the state associated with an "Attendee" to that state of the entry and the state associated with an "Attendee" to that
entry. entry.
The state of an entry is defined by the "STATUS" property and is The state of an entry is defined by the "STATUS" property and is
controlled by the "Organizer." There is no default value for the controlled by the "Organizer." There is no default value for the
"STATUS" property. The "Organizer" sets the "STATUS" property to the "STATUS" property. The "Organizer" sets the "STATUS" property to the
appropriate value for each calendar entry. appropriate value for each calendar entry.
The state of a particular "Attendee" relative to an entry is defined by The state of a particular "Attendee" relative to an entry is defined by
the "attstat" parameter in the "ATTENDEE" property for each "Attendee". the "partstat" parameter in the "ATTENDEE" property for each "Attendee".
When an "Organizer" issues the initial entry, "Attendee" status is When an "Organizer" issues the initial entry, "Attendee" status is
unknown. The "Organizer" specifies this by setting the "attstat" unknown. The "Organizer" specifies this by setting the "partstat"
parameter to "needs-action". Each "Attendee" modifies their "ATTENDEE" parameter to "NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE"
property "attstat" parameter to an appropriate value as part of a property "partstat" parameter to an appropriate value as part of a
"REPLY" message sent back to the "Organizer". "REPLY" message sent back to the "Organizer".
Silverberg/Mansour/Dawson/Hopson 10 Expires September 1998
2.1.2 Delegation 2.1.2 Delegation
Delegation is defined as the process by which an "Attendee" grants Delegation is defined as the process by which an "Attendee" grants
another CU (or several CUs) the right to attend on their behalf. The another CU (or several CUs) the right to attend on their behalf. The
"Organizer" is made aware of this change because the delegating "Organizer" is made aware of this change because the delegating
"Attendee" informs the "Organizer" of this change. These steps are "Attendee" informs the "Organizer". These steps are detailed in the
detailed in the REQUEST method section. REQUEST method section.
2.1.3 Acting on Behalf of other Calendar Users 2.1.3 Acting on Behalf of other Calendar Users
In many organizations one user will act on behalf of another to organize In many organizations one user will act on behalf of another to organize
and/or respond to meeting requests. ITIP provides two mechanisms that and/or respond to meeting requests. ITIP provides two mechanisms that
support these activities. support these activities.
First, the "Organizer" is treated as a special entity, separate from First, the "Organizer" is treated as a special entity, separate from
"Attendees". All responses from "Attendees" flow to the "Organizer", "Attendees". All responses from "Attendees" flow to the "Organizer",
making it easy to separate a calendar user organizing a meeting from making it easy to separate a calendar user organizing a meeting from
calendar users attending the meeting. Additionally, iCalendar provides calendar users attending the meeting. Additionally, iCalendar provides
descriptive roles for each "Attendee". For instance, a role of "chair" descriptive roles for each "Attendee". For instance, a role of "chair"
may be ascribed to one or more "Attendees". The "chair and the may be ascribed to one or more "Attendees". The "chair" and the
"Organizer" may or may not be the same calendar user. This maps well to "Organizer" may or may not be the same calendar user. This maps well to
scenarios where an assistant may manage meeting logistics for another scenarios where an assistant may manage meeting logistics for another
individual who chairs a one-time or recurring meeting. individual who chairs a meeting.
Second, a "sent-by" parameter may be specified in either the "Organizer" Second, a "sent-by" parameter may be specified in either the "Organizer"
or "Attendee" properties. When specified, the "sent-by" parameter or "Attendee" properties. When specified, the "sent-by" parameter
indicates that the responding CU acted on behalf of the specified indicates that the responding CU acted on behalf of the specified
"Attendee" or "Organizer". "Attendee" or "Organizer".
2.1.4 Component Revisions
The "SEQUENCE" property is used by the "Organizer" to indicate revisions
to the calendar component. The rules for incrementing the "SEQUENCE"
number are defined in [iCAL]. For clarity, these rules are paraphrased
Silverberg/Mansour/Daws/Hopson 10 Expires November 1998
here in terms of how they are applied in [iTIP]. For a given "UID" in a
calendar component:
. For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
value is incremented according to the rules defined in [iCAL].
. The "SEQUENCE" property value MUST be incremented each time the
"Organizer" uses the "ADD" or "CANCEL" methods.
. The "SEQUENCE" property value MUST NOT be incremented when using
"REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
delegation "REQUEST".
In some circumstances the "Organizer" may not have received responses to
the final revision sent out. In this situation, the "Organizer" may wish
to send an update "REQUEST", and set "RSVP=TRUE" for all "Attendees", so
that current responses can be collected.
The value of the "SEQUENCE" property contained in a response from an
"Attendee" may not always match the "Organizer's" revision.
Implementations may choose to have the CUA indicate to the CU that the
response is to an entry that has been revised and allow the CU to decide
whether or not to accept the response.
2.1.5 Message Sequencing
CUAs that handle the [iTIP] application protocol must often correlate a
component in a calendar store with a component received in the [iTIP]
message. For example, an event may be updated with a later revision of
the same event. To accomplish this, a CUA must correlate the version of
the event already in its calendar store with the version sent in the
[iTIP] message. In addition to this correlation, there are several
factors that can cause [iTIP] messages to arrive in an unexpected order.
That is, an "Organizer" could receive a reply to an earlier revision of
a component AFTER receiving a reply to a later revision.
To maximize interoperability and to handle messages that arrive in an
unexpected order, use the following rules:
1. The primary key for referencing a particular iCalendar component is
the "UID" property value. To reference an instance of a recurring
component, the primary key is composed of the "UID" and the
"RECURRENCE-ID" properties.
2. The secondary key for referencing a component is the "SEQUENCE"
property value. For components where the "UID" is the same, the
component with the highest numeric value for the "SEQUENCE" property
obsoletes all other revisions of the component with lower values.
3. "Attendees" send "REPLY" messages to the "Organizer". For replies
where the "UID" property value is the same, the value of the
"SEQUENCE" property indicates the revision of the component to which
Silverberg/Mansour/Daws/Hopson 11 Expires November 1998
the "Attendee" is replying. The reply with the highest numeric value
for the "SEQUENCE" property obsoletes all other replies with lower
values.
4. In situations where the "UID" and "SEQUENCE" properties match, the
"DTSTAMP" property is used as the tie-breaker. The component with the
latest "DTSTAMP" overrides all others. Similarly, for "Attendee"
responses where the "UID" property values match and the "SEQUENCE"
property values match, the response with the latest "DTSTAMP"
overrides all others.
Hence, CUAs must persist the following component properties: "UID",
"RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each
"ATTENDEE" property of a component CUAs must persist the "SEQUENCE" and
"DTSTAMP" property values associated with the "Attendee's" response.
3 Application Protocol Elements 3 Application Protocol Elements
ITIP messages are "text/calendar" MIME entities that contain calendaring ITIP messages are "text/calendar" MIME entities that contain calendaring
and scheduling information. The particular type of [ICAL] message is and scheduling information. The particular type of [iCAL] message is
referred to as the "method type". Each method type is identified by a referred to as the "method type". Each method type is identified by a
"METHOD" property specified as part of the "text/calendar" content type. "METHOD" property specified as part of the "text/calendar" content type.
The table below shows various combinations of calendar components and The table below shows various combinations of calendar components and
the method types that this memo supports. the method types that this memo supports.
+=================================================+ +=================================================+
| | VEVENT | VTODO | VJOURNAL | VFREEBUSY | | | VEVENT | VTODO | VJOURNAL | VFREEBUSY |
|=================================================| |=================================================|
|Publish | Yes | Yes | Yes | Yes | |Publish | Yes | Yes | Yes | Yes |
|Request | Yes | Yes | No | Yes | |Request | Yes | Yes | No | Yes |
|Refresh | Yes | Yes | No | No | |Refresh | Yes | Yes | No | No |
|Cancel | Yes | Yes | Yes | No | |Cancel | Yes | Yes | Yes | No |
|Add | Yes | Yes | Yes | No | |Add | Yes | Yes | Yes | No |
|Reply | Yes | Yes | No | Yes | |Reply | Yes | Yes | No | Yes |
|Counter | Yes | Yes | No | No | |Counter | Yes | Yes | No | No |
|Decline- | | | | | |Decline- | | | | |
|Counter | Yes | Yes | No | No | |Counter | Yes | Yes | No | No |
+=================================================+ +=================================================+
Silverberg/Mansour/Dawson/Hopson 11 Expires September 1998
Each method type is defined in terms of its associated components and Each method type is defined in terms of its associated components and
properties. Some components and properties are required, some are properties. Some components and properties are required, some are
optional and others are excluded. The restrictions are expressed in this optional and others are excluded. The restrictions are expressed in this
document using a simple "restriction table". The first column indicates document using a simple "restriction table". The first column indicates
the name of a component or property. Properties of the iCalendar object the name of a component or property. Properties of the iCalendar object
are not indented. Properties of a component are indented. The second are not indented. Properties of a component are indented. The second
column contains "MUST" if the component or property must be present, column contains "MUST" if the component or property must be present,
"MAY" if the component or property is optional, and "NOT" if the "MAY" if the component or property is optional, and "NOT" if the
component or property must not be present. Entries in the second column component or property must not be present. Entries in the second column
sometimes contain comments for further clarification. sometimes contain comments for further clarification.
Silverberg/Mansour/Daws/Hopson 12 Expires November 1998
3.1 Common Component Restriction Tables 3.1 Common Component Restriction Tables
The restriction table below applies to properties of the iCalendar
object. That is, the properties at the outermost scope. The presence
column uses the following values to assert whether a property is
required, is optional and the number of times it may appear in the
iCalendar object.
Presence Value Description
--------------------------------------------------------------
1 One instance MUST be present
1+ At least one instance MUST be present
0 Instances of this property Must NOT be present
0+ Multiple instances MAY be present
0 or 1 Up to 1 instance of this property MAY be present
---------------------------------------------------------------
The tables also call out "X-PROPERTY" and "X-COMPONENT" to show where
vendor-specific properties and components can appear. The tables do not
lay out the restrictions of property parameters. Those restrictions are
defined in [iCAL].
Component/Property Presence
------------------- ----------------------------------------------
CALSCALE 0 or 1
PRODID 1
VERSION 1 Value MUST be "2.0"
X-PROPERTY 0+
DateTime values MAY refer to a "VTIMEZONE" component. The property DateTime values MAY refer to a "VTIMEZONE" component. The property
restrictions in the table below apply to any "VTIMEZONE" component in an restrictions in the table below apply to any "VTIMEZONE" component in an
ITIP message. ITIP message.
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
VTIMEZONE MUST be present if any date/time refers to a VTIMEZONE 0+ MUST be present if any date/time refers to
timezone timezone
LAST-MODIFIED MAY DAYLIGHT 0+ MUST be one or more of either STANDARD or
TZID MUST DAYLIGHT
TZURL MAY COMMENT 0 or 1
STANDARD MUST DTSTART 1 MUST be local time format
DTSTART MUST be present if RRULE is present RDATE 0+ if present RRULE MUST NOT be present
TZOFFSETFROM MUST RRULE 0+ if present RDATE MUST NOT be present
TZOFFSETTO MUST TZNAME 0 or 1
COMMENT MAY TZOFFSET 1
RDATE MAY be present, if present RRULE must not be TZOFFSETFROM 1
present TZOFFSETTO 1
RRULE MAY be present, if present RDATE must not be X-PROPERTY 0+
present LAST-MODIFIED 0 or 1
TZNAME MAY STANDARD 0+ MUST be one or more of either STANDARD or
DAYLIGHT MAY DAYLIGHT
DTSTART MUST COMMENT 0 or 1
TZOFFSET MUST
COMMENT MAY Silverberg/Mansour/Daws/Hopson 13 Expires November 1998
RDATE MAY be present, if present RRULE must not be DTSTART 1 MUST be local time format
present RDATE 0+ if present RRULE MUST NOT be present
RRULE MAY be present, if present RDATE must not be RRULE 0+ if present RDATE MUST NOT be present
present TZNAME 0 or 1
TZNAME MAY TZOFFSETFROM 1
TZOFFSETTO 1
X-PROPERTY 0+
TZID 1
TZURL 0 or 1
X-PROPERTY 0+
The property restrictions in the table below apply to any "VALARM" The property restrictions in the table below apply to any "VALARM"
component in an ITIP message. component in an ITIP message.
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
VALARM MAY VALARM 0+
ALARM-TYPE MUST ACTION 1
DURATION MUST ATTACH 0+
DESCRIPTION 0 or 1
Silverberg/Mansour/Dawson/Hopson 12 Expires September 1998 DURATION 0 or 1 if present REPEAT MUST be present
REPEAT MUST REPEAT 0 or 1 if present DURATION MUST be present
TRIGGER MUST SUMMARY 0 or 1
ATTACH MAY TRIGGER 1
DESCRIPTION MAY X-PROPERTY 0+
SUMMARY MAY
COMMENT NOT
CREATED NOT
LAST-MODIFIED NOT
RELATED-TO NOT
URL NOT
3.2 Methods for VEVENT Calendar Components 3.2 Methods for VEVENT Calendar Components
This section defines the property set restrictions for the method types This section defines the property set restrictions for the method types
that are applicable to the "VEVENT" calendar component. Each method is that are applicable to the "VEVENT" calendar component. Each method is
defined using a table that clarifies the property constraints that defined using a table that clarifies the property constraints that
define the particular method. define the particular method.
The following summarizes the methods that are defined for the "VEVENT" The following summarizes the methods that are defined for the "VEVENT"
calendar component. calendar component.
skipping to change at line 567 skipping to change at line 695
| | event. | | | event. |
| | | | | |
| REQUEST | Make a request for an event. This is an explicit | | REQUEST | Make a request for an event. This is an explicit |
| | invitation to one or more "Attendees". Event | | | invitation to one or more "Attendees". Event |
| | Requests are also used to update or change an | | | Requests are also used to update or change an |
| | existing event. Clients that cannot handle | | | existing event. Clients that cannot handle |
| | REQUEST may degrade the event to view it as an | | | REQUEST may degrade the event to view it as an |
| | PUBLISH. | | | PUBLISH. |
| | | | | |
| REPLY | Reply to an event request. Clients may set their | | REPLY | Reply to an event request. Clients may set their |
| | status ("attstat") to ACCEPTED, DECLINED, | | | status ("partstat") to ACCEPTED, DECLINED, |
Silverberg/Mansour/Daws/Hopson 14 Expires November 1998
| | TENTATIVE, or DELEGATED. | | | TENTATIVE, or DELEGATED. |
| | | | | |
| ADD | Add one or more instances to an existing event. | | ADD | Add one or more instances to an existing event. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | event. | | | event. |
| | | | | |
| REFRESH | A request is sent to an "Organizer" by an | | REFRESH | A request is sent to an "Organizer" by an |
| | "Attendee" asking for the latest version of an | | | "Attendee" asking for the latest version of an |
| | event to be resent to the requester. | | | event to be resent to the requester. |
| | | | | |
| COUNTER | Counter a REQUEST with an alternative proposal, | | COUNTER | Counter a REQUEST with an alternative proposal, |
| | Sent by an "Attendee" to the "Organizer". | | | Sent by an "Attendee" to the "Organizer". |
| | | | | |
| DECLINECOUNTER | Decline a counter proposal. Sent to an | | DECLINECOUNTER | Decline a counter proposal. Sent to an |
Silverberg/Mansour/Dawson/Hopson 13 Expires September 1998
| | "Attendee" by the "Organizer". | | | "Attendee" by the "Organizer". |
+================+==================================================+ +================+==================================================+
3.2.1 PUBLISH 3.2.1 PUBLISH
The "PUBLISH" method in a "VEVENT" calendar component is an unsolicited The "PUBLISH" method in a "VEVENT" calendar component is an unsolicited
posting of an iCalendar object. Any CU may add published components to posting of an iCalendar object. Any CU may add published components to
their calendar. The "Organizer" MUST be present in a published iCalendar their calendar. The "Organizer" MUST be present in a published iCalendar
component. Other "Attendees" MAY be present. However, no replies are component. "Attendees" MUST NOT be present. Its expected usage is for
expected. Its expected usage is for encapsulating an arbitrary event as encapsulating an arbitrary event as an iCalendar object. The "Organizer"
an iCalendar object. The "Organizer" may subsequently update (with may subsequently update (with another "PUBLISH" method), add instances
another "PUBLISH" method), add instances to (with an "ADD" method), or to (with an "ADD" method), or cancel (with a "CANCEL" method) a
cancel (with a "CANCEL" method) a previously published "VEVENT" calendar previously published "VEVENT" calendar component.
component.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST equal "PUBLISH"
VERSION MUST be "2.0" VEVENT 1+
METHOD MUST be "PUBLISH" DTSTAMP 1
VEVENT MUST DTSTART 1
DTSTAMP MUST ORGANIZER 1
DTSTART MUST SUMMARY 1 Can be null.
ORGANIZER MUST UID 1
RECURRENCE-ID MUST only if referring to an instance of a RECURRENCE-ID 0 or 1 only if referring to an instance of a
recurring calendar component. Otherwise it recurring calendar component. Otherwise it
must NOT be present. MUST NOT be present.
SEQUENCE MUST be present if not 0, may be present if 0 SEQUENCE 0 or 1 MUST be present if value is greater than 0,
SUMMARY MUST; may be null. MAY be present if 0
UID MUST ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of values
ATTENDEE MAY CLASS 0 or 1
ATTACH MAY COMMENT 0 or 1
CATEGORIES MAY CONTACT 0+
CLASS MAY CREATED 0 or 1
COMMENT MAY DESCRIPTION 0 or 1 Can be null
CONTACT MAY
CREATED MAY
DESCRIPTION MAY be present and MAY be NULL
DTEND MAY
EXDATE MAY
EXRULE MAY
GEO MAY
LAST-MODIFIED MAY
LOCATION MAY
PRIORITY MAY
RELATED-TO MAY
RDATE MAY
RESOURCES MAY
RRULE MAY
Silverberg/Mansour/Dawson/Hopson 14 Expires September 1998
STATUS MAY be one of TENTATIVE/CONFIRMED/CANCELLED
TRANSP MAY
URL MAY
DURATION NOT Silverberg/Mansour/Daws/Hopson 15 Expires November 1998
DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PRIORITY 0 or 1
RDATE 0+
RELATED-TO 0+
RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
VTODO NOT ATTENDEE 0
VJOURNAL NOT REQUEST-STATUS 0
VTIMEZONE MUST be present if any date/time refers to a VALARM 0+
VFREEBUSY 0
VJOURNAL 0
VTODO 0
VTIMEZONE 0+ MUST be present if any date/time refers to a
timezone timezone
VALARM MAY X-COMPONENT 0+
VFREEBUSY NOT
X-TOKENS MAY
3.2.2 REQUEST 3.2.2 REQUEST
The "REQUEST" method in a "VEVENT" component provides the following The "REQUEST" method in a "VEVENT" component provides the following
scheduling functions: scheduling functions:
. Invite "Attendees" to an event; . Invite "Attendees" to an event;
. Reschedule an existing event; . Reschedule an existing event;
. Response to a REFRESH request;
. Update the details of an existing event, without rescheduling it; . Update the details of an existing event, without rescheduling it;
. Update the status of "Attendees" of an existing event, without . Update the status of "Attendees" of an existing event, without
rescheduling it; rescheduling it;
. Reconfirm an existing event, without rescheduling it; . Reconfirm an existing event, without rescheduling it;
. To forward a VEVENT to another uninvited CU. . Forward a "VEVENT" to another uninvited CU.
. For an existing "VEVENT" calendar component, delegate the role of . For an existing "VEVENT" calendar component, delegate the role of
"Attendee" to another CU; "Attendee" to another CU;
. For an existing "VEVENT" calendar component, changing the role of . For an existing "VEVENT" calendar component, changing the role of
"Organizer" to another CU. "Organizer" to another CU.
The "Organizer" originates the "REQUEST". The recipients of the The "Organizer" originates the "REQUEST". The recipients of the
"REQUEST" method are the CUs invited to the event, the "Attendees". "REQUEST" method are the CUs invited to the event, the "Attendees".
"Attendees" use the "REPLY" method to convey attendance status to the "Attendees" use the "REPLY" method to convey attendance status to the
"Organizer". "Organizer".
The "UID" and "SEQUENCE" properties are used to distinguish the various The "UID" and "SEQUENCE" properties are used to distinguish the various
uses of the "REQUEST" method. If the "UID" property value in the uses of the "REQUEST" method. If the "UID" property value in the
Silverberg/Mansour/Daws/Hopson 16 Expires November 1998
"REQUEST" is not found on the recipient's calendar, then the "REQUEST" "REQUEST" is not found on the recipient's calendar, then the "REQUEST"
is for a new "VEVENT" calendar component. If the "UID" property value is is for a new "VEVENT" calendar component. If the "UID" property value is
found on the recipient's calendar, then the "REQUEST" is for a found on the recipient's calendar, then the "REQUEST" is for a
rescheduling, an update, or a reconfirm of the "VEVENT" calendar rescheduling, an update, or a reconfirm of the "VEVENT" calendar
component. component.
For the "REQUEST" method, multiple "VEVENT" components in a single
iCalendar object are only permitted when for components with the same
"UID" property. That is, a series of recurring events may have
instance-specific information. In this case, multiple "VEVENT"
components are needed to express the entire series.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "REQUEST"
VERSION MUST be "2.0" VEVENT 1+ All components MUST have the same UID
METHOD MUST be "REQUEST" ATTENDEE 1+
DTSTAMP 1
Silverberg/Mansour/Dawson/Hopson 15 Expires September 1998 DTSTART 1
ORGANIZER 1
SEQUENCE 0 or 1 MUST be present if value is greater than 0,
MAY be present if 0
SUMMARY 1 Can be null
UID 1
VEVENT MUST ATTACH 0+
ATTENDEE MUST CATEGORIES 0 or 1 This property may contain a list of values
DTSTAMP MUST CLASS 0 or 1
DTSTART MUST COMMENT 0 or 1
ORGANIZER MUST CONTACT 0+
RECURRENCE-ID MUST only if referring to an instance of a CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PRIORITY 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 only if referring to an instance of a
recurring calendar component. Otherwise it recurring calendar component. Otherwise it
must NOT be present. MUST NOT be present.
SEQUENCE MUST be present if non-zero, may be present if zero RELATED-TO 0+
SUMMARY MUST be present, may be NULL REQUEST-STATUS 0+
UID MUST RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED
TRANSP 0 or 1
URL 0 or 1
ATTACH MAY Silverberg/Mansour/Daws/Hopson 17 Expires November 1998
CATEGORIES MAY X-PROPERTY 0+
CLASS MAY
COMMENT MAY
CONTACT MAY
CREATED MAY
DESCRIPTION MAY be present and may be NULL
DTEND MAY
EXDATE MAY
EXRULE MAY
GEO MAY
LAST-MODIFIED MAY
LOCATION MAY
PRIORITY MAY
RDATE MAY
RELATED-TO MAY
RESOURCES MAY
RRULE MAY
STATUS MAY be one of TENTATIVE/CONFIRMED
TRANSP MAY
URL MAY
DURATION NOT VALARM 0+
REQUEST-STATUS NOT VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VTODO NOT VFREEBUSY 0
VJOURNAL NOT VJOURNAL 0
VTIMEZONE MUST be present if any date/time refers to a VTODO 0
timezone
VALARM MAY
VFREEBUSY NOT
X-TOKENS MAY
3.2.2.1 Rescheduling an Event 3.2.2.1 Rescheduling an Event
The "REQUEST" method may be used to reschedule an event. A rescheduled The "REQUEST" method may be used to reschedule an event. A rescheduled
event involves a change to the existing event in terms of its time or event involves a change to the existing event in terms of its time or
recurrence intervals and possibly the location or description. If the recurrence intervals and possibly the location or description. If the
recipient CUA of a "REQUEST" method finds that the "UID" property value recipient CUA of a "REQUEST" method finds that the "UID" property value
already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP") already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP")
property value in the "REQUEST" method is greater than the value for the property value in the "REQUEST" method is greater than the value for the
Silverberg/Mansour/Dawson/Hopson 16 Expires September 1998
existing event, then the "REQUEST" method describes a rescheduling of existing event, then the "REQUEST" method describes a rescheduling of
the event. the event.
3.2.2.2 Updating or Reconfirmation of an Event 3.2.2.2 Updating or Reconfirmation of an Event
The "REQUEST" method may be used to update or reconfirm an event. An The "REQUEST" method may be used to update or reconfirm an event. An
update to an existing event does not involve changes to the time or update to an existing event does not involve changes to the time or
recurrence intervals, and might not involve a change to the location or recurrence intervals, and might not involve a change to the location or
description for the event. If the recipient CUA of a "REQUEST" method description for the event. If the recipient CUA of a "REQUEST" method
finds that the "UID" property value already exists on the calendar and finds that the "UID" property value already exists on the calendar and
that the "SEQUENCE" property value in the "REQUEST" is the same as the that the "SEQUENCE" property value in the "REQUEST" is the same as the
value for the existing event, then the "REQUEST" method describes an value for the existing event, then the "REQUEST" method describes an
update of the event details, but no rescheduling of the event. update of the event details, but no rescheduling of the event.
The update "REQUEST" method is the appropriate response to a "REFRESH" The update "REQUEST" method is the appropriate response to a "REFRESH"
method sent from an "Attendee" to the "Organizer" of an event. method sent from an "Attendee" to the "Organizer" of an event.
The "Organizer" of an event may also send unsolicited "REQUEST" methods. The "Organizer" of an event may also send unsolicited "REQUEST" methods.
The unsolicited "REQUEST" methods may be used to update the details of The unsolicited "REQUEST" methods may be used to update the details of
the event without rescheduling it, to update the "attstat" parameter of the event without rescheduling it, to update the "partstat" parameter of
"Attendees", or to reconfirm the event. "Attendees", or to reconfirm the event.
3.2.2.3 Delegating an Event to another CU 3.2.2.3 Delegating an Event to another CU
Some calendar and scheduling systems allow "Attendees" to delegate their Some calendar and scheduling systems allow "Attendees" to delegate their
presence at an event to another calendar user. ITIP supports this presence at an event to another calendar user. ITIP supports this
concept using the following workflow. Any "Attendee" may delegate their concept using the following workflow. Any "Attendee" may delegate their
right to participate in a calendar VEVENT to another CU. The implication right to participate in a calendar VEVENT to another CU. The implication
is that the delegate participates in lieu of the original "Attendee"; is that the delegate participates in lieu of the original "Attendee";
NOT in addition to the "Attendee". The delegator MUST notify the NOT in addition to the "Attendee". The delegator MUST notify the
"Organizer" of this action using the steps outlined below. "Organizer" of this action using the steps outlined below.
Implementations may support or restrict delegation as they see fit. For Implementations may support or restrict delegation as they see fit. For
Silverberg/Mansour/Daws/Hopson 18 Expires November 1998
instance, some implementations may restrict a delegate from delegating a instance, some implementations may restrict a delegate from delegating a
"REQUEST" to another CU. "REQUEST" to another CU.
The "Delegator" of an event forwards the existing "REQUEST" to the The "Delegator" of an event forwards the existing "REQUEST" to the
"Delegate". The "REQUEST" method MUST include an "ATTENDEE" property "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
with the calendar address of the "Delegate". The "Delegator" MUST also with the calendar address of the "Delegate". The "Delegator" MUST also
send a "REPLY" method to the "Organizer" with the "Delegator's" send a "REPLY" method to the "Organizer" with the "Delegator's"
"ATTENDEE" property "attstat" parameter value set to "delegated". In "ATTENDEE" property "partstat" parameter value set to "delegated". In
addition, the "delegated-to" parameter MUST be included with the addition, the "delegated-to" parameter MUST be included with the
calendar address of the "Delegate". calendar address of the "Delegate".
In response to the request, the "Delegate" MUST send a "REPLY" method to In response to the request, the "Delegate" MUST send a "REPLY" method to
the "Organizer" and optionally, to the "Delegator". The "REPLY" method " the "Organizer" and optionally, to the "Delegator". The "REPLY" method "
SHOULD include the "ATTENDEE" property with the "delegated-from" SHOULD include the "ATTENDEE" property with the "delegated-from"
parameter value of the "Delegator's" calendar address. parameter value of the "Delegator's" calendar address.
Silverberg/Mansour/Dawson/Hopson 17 Expires September 1998 The "Delegator" may continue to receive updates to the event even though
they will not be attending. This is accomplished by When the "Delegator"
sends "REPLY" to the "Organizer"
3.2.2.4 Changing the Organizer 3.2.2.4 Changing the Organizer
The situation may arise where the "Organizer" of a VEVENT is no longer The situation may arise where the "Organizer" of a VEVENT is no longer
able to perform the "Organizer" role and abdicates without passing on able to perform the "Organizer" role and abdicates without passing on
the "Organizer" role to someone else. When this occurs the "Attendees" the "Organizer" role to someone else. When this occurs the "Attendees"
of the VEVENT may use out-of-band mechanisms to communicate the of the VEVENT may use out-of-band mechanisms to communicate the
situation and agree upon a new "Organizer". The new "Organizer" should situation and agree upon a new "Organizer". The new "Organizer" should
then send out a new "REQUEST" with a modified version of the VEVENT in then send out a new "REQUEST" with a modified version of the VEVENT in
which the "SEQUENCE" number has been incremented and value of the which the "SEQUENCE" number has been incremented and value of the
skipping to change at line 831 skipping to change at line 965
iTIP supports the notion of one CU acting on behalf of another. Using iTIP supports the notion of one CU acting on behalf of another. Using
the "sent-by" parameter, a calendar user could send an updated "VEVENT" the "sent-by" parameter, a calendar user could send an updated "VEVENT"
REQUEST. In the case where one CU sends on behalf of another CU, the REQUEST. In the case where one CU sends on behalf of another CU, the
"Attendee" responses are still directed back towards the CU designated "Attendee" responses are still directed back towards the CU designated
as "Organizer". as "Organizer".
3.2.2.6 Forwarding to An Uninvited CU 3.2.2.6 Forwarding to An Uninvited CU
An "Attendee" invited to an event may invite another uninvited CU to the An "Attendee" invited to an event may invite another uninvited CU to the
event. The invited "Attendee" accomplishes this by forwarding the event. The invited "Attendee" accomplishes this by forwarding the
original "REQUEST" method to the uninvited CU. Whether the uninvited CU original "REQUEST" method to the uninvited CU. The "Organizer" decides
is added to the attendee list, and thus informed of changes to the whether or not the uninvited CU is added to the attendee list. If the
"VEVENT" calendar component, is an issue left to individual "Organizer" decides not to add the uninvited CU no further action is
implementations. It is not required. It is important to note that when
forwarding a "REQUEST" to another CU, the forwarding "Attendee" MUST NOT Silverberg/Mansour/Daws/Hopson 19 Expires November 1998
make changes to the VEVENT property set. required, however the "Organizer" MAY send the uninvited CU a "CANCEL"
message. If the "Organizer" decides to add uninvited CU, a new
"ATTENDEE" property is added for the uninvited CU with its property
parameters set as the "Organizer" deems appropriate. When forwarding a
"REQUEST" to another CU, the forwarding "Attendee" MUST NOT make changes
to the VEVENT property set.
3.2.2.7 Updating Attendee Status 3.2.2.7 Updating Attendee Status
The "Organizer" of an event may also request updated status from one or The "Organizer" of an event may also request updated status from one or
more "Attendees. The "Organizer" sends a "REQUEST" method to the more "Attendees. The "Organizer" sends a "REQUEST" method to the
"Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The
"SEQUENCE" property for the event is not changed from its previous "SEQUENCE" property for the event is not changed from its previous
value. A recipient will determine that the only change in the "REQUEST" value. A recipient will determine that the only change in the "REQUEST"
is that their "RSVP" property parameter indicates a request for updated is that their "RSVP" property parameter indicates a request for updated
status. The recipient SHOULD respond with a "REPLY" method indicating status. The recipient SHOULD respond with a "REPLY" method indicating
their current status with respect to the "REQUEST". their current status with respect to the "REQUEST".
3.2.3 REPLY 3.2.3 REPLY
The "REPLY" method in a "VEVENT" calendar component is used to respond The "REPLY" method in a "VEVENT" calendar component is used to respond
(e.g., accept or decline) to a "REQUEST" or to reply to a delegation (e.g., accept or decline) to a "REQUEST" or to reply to a delegation
Silverberg/Mansour/Dawson/Hopson 18 Expires September 1998
"REQUEST". When used to provide a delegation response, the "Delegator" "REQUEST". When used to provide a delegation response, the "Delegator"
SHOULD include the calendar address of the "Delegate" on the "delegated- SHOULD include the calendar address of the "Delegate" on the "delegated-
to" property parameter of the "Delegator's" "ATTENDEE" property. The to" property parameter of the "Delegator's" "ATTENDEE" property. The
"Delegate" SHOULD include the calendar address of the "Delegator" on the "Delegate" SHOULD include the calendar address of the "Delegator" on the
"delegated-from" property parameter of the "Delegate's" "ATTENDEE" "delegated-from" property parameter of the "Delegate's" "ATTENDEE"
property. property.
The "REPLY" method may also be used to respond to an unsuccessful The "REPLY" method may also be used to respond to an unsuccessful
"REQUEST" method. Depending on the value of the "REQUEST-STATUS" "REQUEST" method. Depending on the value of the "REQUEST-STATUS"
property no scheduling action may have been performed. property no scheduling action may have been performed.
The "Organizer" of an event may receive the "REPLY" method from a CU not The "Organizer" of an event may receive the "REPLY" method from a CU not
in the original "REQUEST". For example, a "REPLY" may be received from a in the original "REQUEST". For example, a "REPLY" may be received from a
"Delegate" to an event. In addition, the "REPLY" method may be received "Delegate" to an event. In addition, the "REPLY" method may be received
from an unknown CU (a "Party Crasher"). This uninvited "Attendee" may be from an unknown CU (a "Party Crasher"). This uninvited "Attendee" may be
accepted, or the "Organizer" may cancel the event for the uninvited accepted, or the "Organizer" may cancel the event for the uninvited
"Attendee" by sending a "CANCEL" method to the uninvited "Attendee". "Attendee" by sending a "CANCEL" method to the uninvited "Attendee".
An "Attendee" can include a message to the "Organizer" using the
"COMMENT" property. For example, if the user indicates tentative
acceptance and wants to let the "Organizer" know why, the reason can be
expressed in the "COMMENT" property value.
The "Organizer" may also receive a "REPLY" from one CU on behalf of The "Organizer" may also receive a "REPLY" from one CU on behalf of
another. Like the scenario enumerated above for the "Organizer", another. Like the scenario enumerated above for the "Organizer",
"Attendees" may have another CU respond on their behalf. This is done "Attendees" may have another CU respond on their behalf. This is done
using the "sent-by" parameter. using the "sent-by" parameter.
The optional properties listed in the table below (those listed as Silverberg/Mansour/Daws/Hopson 20 Expires November 1998
"MAY") MUST NOT be changed from those of the original request. If The optional properties listed in the table below (those listed as "0+"
or "0 or 1") MUST NOT be changed from those of the original request. If
property changes are desired the COUNTER message must be used. property changes are desired the COUNTER message must be used.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "REPLY"
VERSION MUST be "2.0"
METHOD MUST be "REPLY"
VEVENT MUST VEVENT 1+ All components MUST have the same UID
ATTENDEE MUST be the address of the Attendee replying. ATTENDEE 1 MUST be the address of the Attendee
DTSTAMP MUST replying.
ORGANIZER MUST DTSTAMP 1
RECURRENCE-ID MUST only if referring to an instance of a ORGANIZER 1
RECURRENCE-ID 0 or 1 only if referring to an instance of a
recurring calendar component. Otherwise it recurring calendar component. Otherwise it
must NOT be present. must NOT be present.
SEQUENCE MUST if non-zero UID 1 MUST be the UID of the original REQUEST
UID MUST be the UID of the original REQUEST
ATTACH MAY
COMMENT MAY
CONTACT MAY
EXDATE MAY
EXRULE MAY
REQUEST-STATUS MAY
CATEGORIES MAY SEQUENCE 0 or 1 MUST if non-zero, MUST be the sequence
number of the original REQUEST. MAY be
present if 0.
Silverberg/Mansour/Dawson/Hopson 19 Expires September 1998 ATTACH 0+
CLASS MAY CATEGORIES 0 or 1 This property may contain a list of values
CREATED MAY CLASS 0 or 1
DESCRIPTION MAY COMMENT 0 or 1
DTSTART MAY CONTACT 0+
DTEND MAY CREATED 0 or 1
DURATION MAY DESCRIPTION 0 or 1
GEO MAY DTEND 0 or 1 if present DURATION MUST NOT be present
LAST-MODIFIED MAY DTSTART 0 or 1
PRIORITY MAY DURATION 0 or 1 if present DTEND MUST NOT be present
RELATED-TO MAY EXDATE 0+
RESOURCES MAY EXRULE 0+
RDATE MAY GEO 0 or 1
RRULE MAY LAST-MODIFIED 0 or 1
STATUS MAY LOCATION 0 or 1
SUMMARY MAY PRIORITY 0 or 1
TRANSP MAY RDATE 0+
URL MAY RELATED-TO 0+
RESOURCES 0 or 1 This property MAY contain a list of values
REQUEST-STATUS 0+
RRULE 0+
STATUS 0 or 1
SUMMARY 0 or 1
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
VTIMEZONE MUST be present if any date/time refers to a VTIMEZONE 0 or 1 MUST be present if any date/time refers to a
timezone timezone
X-TOKENS NOT
VTODO NOT Silverberg/Mansour/Daws/Hopson 21 Expires November 1998
VJOURNAL NOT X-COMPONENT 0+
VFREEBUSY NOT
VALARM NOT VALARM 0
VFREEBUSY 0
VJOURNAL 0
VTODO 0
3.2.4 ADD 3.2.4 ADD
The "ADD" method in a "VEVENT" calendar component is used to add one or The "ADD" method in a "VEVENT" calendar component is used to add one or
more instances to an existing "VEVENT". Unlike the "REQUEST" method, more instances to an existing "VEVENT". Unlike the "REQUEST" method,
when using issuing an "ADD" method, the "Organizer" does not send the when using issuing an "ADD" method, the "Organizer" does not send the
full "VEVENT" description; only the new instance(s). The "ADD" method is full "VEVENT" description; only the new instance(s). The "ADD" method is
especially useful if there are instance-specific properties to be especially useful if there are instance-specific properties to be
preserved in a recurring "VEVENT". For instance, an "Organizer" may have preserved in a recurring "VEVENT". For instance, an "Organizer" may have
originally scheduled a weekly Thursday meeting. At some point, several originally scheduled a weekly Thursday meeting. At some point, several
skipping to change at line 964 skipping to change at line 1110
recipient SHOULD send a "REFRESH" to the "Organizer" in order to be recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
updated with the latest version of the "VEVENT". If an "Attendee" updated with the latest version of the "VEVENT". If an "Attendee"
implementation does not support the "ADD" method it should respond with implementation does not support the "ADD" method it should respond with
a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH". a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH".
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "ADD"
VEVENT 1
DTSTAMP 1
DTSTART 1
ORGANIZER 1
SEQUENCE 1 MUST be greater than 0
SUMMARY 1 Can be null
UID 1 MUST match that of the original event
Silverberg/Mansour/Dawson/Hopson 20 Expires September 1998 ATTACH 0+
ATTENDEE 0+
CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+
VERSION MUST be "2.0" Silverberg/Mansour/Daws/Hopson 22 Expires November 1998
METHOD MUST be "ADD" EXRULE 0+
VEVENT MUST GEO 0 or 1
DTSTAMP MUST LAST-MODIFIED 0 or 1
DTSTART MUST LOCATION 0 or 1
ORGANIZER MUST PRIORITY 0 or 1
SEQUENCE MUST be greater than 0 RDATE 0+
SUMMARY MUST be present, may be NULL RELATED-TO 0+
UID MUST match that of the original event RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
ATTACH MAY RECURRENCE-ID 0
ATTENDEE MAY REQUEST-STATUS 0
CATEGORIES MAY
CLASS MAY
COMMENT MAY
CONTACT MAY
CREATED MAY
DESCRIPTION MAY be present and may be NULL
DTEND MAY
EXDATE MAY
EXRULE MAY
GEO MAY
LAST-MODIFIED MAY
LOCATION MAY
PRIORITY MAY
RDATE MAY
RELATED-TO MAY
RESOURCES MAY
RRULE MAY
STATUS MAY be one of TENTATIVE/CONFIRMED
TRANSP MAY
URL MAY
DURATION NOT VALARM 0+
RECURRENCE-ID NOT VTIMEZONE 0+ MUST be present if any date/time refers to
REQUEST-STATUS NOT a timezone
X-COMPONENT 0+
VTODO NOT VFREEBUSY 0
VJOURNAL NOT VTODO 0
VTIMEZONE MUST be present if any date/time refers to a VJOURNAL 0
timezone
VALARM MAY
VFREEBUSY NOT
X-TOKENS MAY
3.2.5 CANCEL 3.2.5 CANCEL
The "CANCEL" method in a "VEVENT" calendar component is used to send a The "CANCEL" method in a "VEVENT" calendar component is used to send a
cancellation notice of an existing event request to the "Attendees". The cancellation notice of an existing event request to the "Attendees". The
message is sent by the "Organizer" of the event. For a recurring event, message is sent by the "Organizer" of the event. For a recurring event,
either the whole event or instances of an event may be cancelled. To either the whole event or instances of an event may be cancelled. To
cancel the complete range of recurring event, the "UID" property value cancel the complete range of recurring event, the "UID" property value
for the event MUST be specified and a "RECURRENCE-ID" MUST NOT be for the event MUST be specified and a "RECURRENCE-ID" MUST NOT be
Silverberg/Mansour/Dawson/Hopson 21 Expires September 1998
specified in the "CANCEL" method. In order to cancel an individual specified in the "CANCEL" method. In order to cancel an individual
instance of the event, the "RECURRENCE-ID" property value for the event instance of the event, the "RECURRENCE-ID" property value for the event
MUST be specified in the "CANCEL" method. MUST be specified in the "CANCEL" method.
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
recurring "VEVENT" calendar component: recurring "VEVENT" calendar component:
(a) the "RECURRENCE-ID" property for an instance in the sequence MUST be (a) the "RECURRENCE-ID" property for an instance in the sequence MUST be
specified with the "RANGE" property parameter value of THISANDPRIOR specified with the "RANGE" property parameter value of THISANDPRIOR
(or THISANDFUTURE) to indicate cancellation of the specified (or THISANDFUTURE) to indicate cancellation of the specified
"VEVENT" calendar component and all instances before (or after); or "VEVENT" calendar component and all instances before (or after); or
(b) individual recurrence instances may be cancelled by specifying (b) individual recurrence instances may be cancelled by specifying
multiple "RECURRENCE-ID" properties corresponding to the instances to multiple "RECURRENCE-ID" properties corresponding to the instances to
be cancelled. be cancelled.
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
incremented.
Silverberg/Mansour/Daws/Hopson 23 Expires November 1998
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "CANCEL"
VERSION MUST be "2.0"
METHOD MUST be "CANCEL"
VEVENT MUST
DTSTAMP MUST
ORGANIZER MUST
RECURRENCE-ID MUST only if referring to one or more instances of
a recurring calendar component. Otherwise it
MUST NOT be present.
SEQUENCE MUST
UID MUST be the UID of the original REQUEST
COMMENT MAY VEVENT 1+ All must have the same UID
STATUS Must be set to "Cancelled". If uninviting specific ATTENDEE 0+ MUST include all "Attendees" being removed
"Attendees" then MUST NOT be included. the event. MUST include all "Attendees" if
the entire event is cancelled.
DTSTAMP 1
ORGANIZER 1
SEQUENCE 1
UID 1 MUST be the UID of the original REQUEST
ATTACH MAY COMMENT 0 or 1
ATTENDEE MAY ATTACH 0+
CATEGORIES MAY CATEGORIES 0 or 1 This property may contain a list of values
CLASS MAY CLASS 0 or 1
CONTACT MAY CONTACT 0+
CREATED MAY CREATED 0 or 1
DESCRIPTION MAY DESCRIPTION 0 or 1
DTSTART MAY DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION MAY DTSTART 0 or 1
DTEND MAY DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE MAY EXDATE 0+
EXRULE MAY EXRULE 0+
GEO MAY GEO 0 or 1
LAST-MODIFIED MAY LAST-MODIFIED 0 or 1
PRIORITY MAY LOCATION 0 or 1
RELATED-TO MAY PRIORITY 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 MUST be present if referring to one or more
or more recurring instances. Otherwise it
MUST NOT be present
RELATED-TO 0+
RESOURCES 0 or 1
RRULE 0+
STATUS 0 or 1 MUST be set to CANCELLED. If uninviting
specific "Attendees" then MUST NOT be
included.
SUMMARY 0 or 1
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
REQUEST-STATUS 0
Silverberg/Mansour/Dawson/Hopson 22 Expires September 1998 VTIMEZONE 0+ MUST be present if any date/time refers to
REQUEST-STATUS MAY a timezone
RESOURCES MAY X-COMPONENT 0+
RDATE MAY
RRULE MAY
STATUS MAY
SUMMARY MAY
TRANSP MAY
URL MAY
VTIMEZONE MUST be present if any date/time refers to a VTODO 0
timezone VJOURNAL 0
X-TOKENS MAY Silverberg/Mansour/Daws/Hopson 24 Expires November 1998
VTODO NOT VFREEBUSY 0
VJOURNAL NOT VALARM 0
VFREEBUSY NOT
VALARM NOT
3.2.6 REFRESH 3.2.6 REFRESH
The "REFRESH" method in a "VEVENT" calendar component is used by The "REFRESH" method in a "VEVENT" calendar component is used by
"Attendees" of an existing event to request an updated description from "Attendees" of an existing event to request an updated description from
the event "Organizer". The "REFRESH" method must specify the "UID" the event "Organizer". The "REFRESH" method must specify the "UID"
property of the event to update. A recurrence instance of an event may property of the event to update. A recurrence instance of an event may
be requested by specifying the "RECURRENCE-ID" property corresponding to be requested by specifying the "RECURRENCE-ID" property corresponding to
the associated event. The "Organizer" responds with the latest the associated event. The "Organizer" responds with the latest
description and version of the event. description and version of the event.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "REFRESH"
VERSION MUST be "2.0"
METHOD MUST be "REFRESH"
VEVENT MUST VEVENT 1
ATTENDEE MUST be the address of requestor ATTENDEE 1 MUST be the address of requestor
DTSTAMP MUST DTSTAMP 1
RECURRENCE-ID MUST only if referring to an instance of a ORGANIZER 1
UID 1 MUST be the UID associated with original
REQUEST
COMMENT 0 or 1
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise it recurring calendar component. Otherwise it
must NOT be present. must NOT be present.
UID MUST be the UID associated with original X-PROPERTY 0+
REQUEST
COMMENT MAY
ATTACH NOT ATTACH 0
ATEGORIES NOT CATEGORIES 0
CLASS NOT CLASS 0
CONTACT MAY CONTACT 0
CREATED NOT CREATED 0
DESCRIPTION 0
DTEND 0
DTSTART 0
DURATION 0
EXDATE 0
EXRULE 0
GEO 0
LAST-MODIFIED 0
LOCATION 0
PRIORITY 0
RDATE 0
RELATED-TO 0
REQUEST-STATUS 0
RESOURCES 0
RRULE 0
SEQUENCE 0
Silverberg/Mansour/Dawson/Hopson 23 Expires September 1998 Silverberg/Mansour/Daws/Hopson 25 Expires November 1998
DESCRIPTION NOT STATUS 0
DTSTART NOT SUMMARY 0
DTEND NOT TRANSP 0
DURATION NOT URL 0
EXDATE NOT
EXRULE NOT
GEO NOT
LAST-MODIFIED NOT
ORGANIZER NOT
PRIORITY NOT
RDATE NOT
RELATED-TO NOT
RESOURCES NOT
REQUEST-STATUS NOT
RRULE NOT
SEQUENCE NOT
SUMMARY NOT
STATUS NOT
TRANSP NOT
URL NOT
VTIMEZONE MUST be present if any date/time refers to a X-COMPONENT 0+
timezone
X-TOKENS MAY VTODO 0
VTODO NOT VJOURNAL 0
VJOURNAL NOT VFREEBUSY 0
VFREEBUSY NOT VTIMEZONE 0
VALARM NOT VALARM 0
3.2.7 COUNTER 3.2.7 COUNTER
The "COUNTER" method for a "VEVENT" calendar component is used by an The "COUNTER" method for a "VEVENT" calendar component is used by an
"Attendee" of an existing event to submit to the "Organizer" a counter "Attendee" of an existing event to submit to the "Organizer" a counter
proposal to the event description. The "Attendee" sends this message to proposal to the event description. The "Attendee" sends this message to
the "Organizer" of the event. the "Organizer" of the event.
The counter proposal is an iCalendar object consisting of a VEVENT The counter proposal is an iCalendar object consisting of a VEVENT
calendar component describing the complete description of the alternate calendar component describing the complete description of the alternate
event. event.
The "Organizer" rejects the counter proposal by sending the "Attendee" a The "Organizer" rejects the counter proposal by sending the "Attendee" a
VEVENT "DECLINE-COUNTER" method. The "Organizer" accepts the counter VEVENT "DECLINECOUNTER" method. The "Organizer" accepts the counter
proposal by sending all of the "Attendees" to the event a VEVENT proposal by rescheduling the event as described in section 3.2.2.1
"REQUEST" method rescheduling the event. In the latter case, the Rescheduling an Event.
"Organizer" SHOULD reset the individual "RSVP" property parameter values
to TRUE on each "ATTENDEE" property in order to force a response by the
"Attendees".
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
Silverberg/Mansour/Dawson/Hopson 24 Expires September 1998
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "COUNTER"
VERSION MUST be "2.0"
METHOD MUST be "COUNTER"
VEVENT MUST VEVENT 1
DTSTAMP MUST DTSTAMP 1
RECURRENCE-ID MUST only if referring to an instance of a DTSTART 1
recurring calendar component. Otherwise it ORGANIZER 1 MUST be the "Organizer" of the original
must NOT be present. event
SEQUENCE MUST be present if non-zero, MAY be present if zero SEQUENCE 1 MUST be present if value is greater than 0,
SUMMARY MUST be present may be NULL MAY be present if 0
UID MUST be the UID associated with the REQUEST SUMMARY 1 Can be null
UID 1 MUST be the UID associated with the REQUEST
being countered being countered
ATTACH MAY ATTACH 0+
ATTENDEE MAY be used to propose other "Attendees" ATTENDEE 0+ Can also be used to propose other
CATEGORIES MAY "Attendees"
CLASS MAY CATEGORIES 0 or 1 This property may contain a list of values
COMMENT MAY CLASS 0 or 1
CONTACT MAY COMMENT 0 or 1
CREATED MAY
DESCRIPTION MAY be present, may be NULL
DTSTART MAY
DTEND MAY
EXDATE MAY
EXRULE MAY
GEO MAY
LAST-MODIFIED MAY
LOCATION MAY
PRIORITY MAY
RDATE MAY
RELATED-TO MAY
RESOURCES MAY
RRULE MAY
STATUS MAY
TRANSP MAY
URL MAY
COMPLETED NOT
DUE NOT
DURATION NOT
ORGANIZER NOT
REQUEST-STATUS NOT
VTIMEZONE MUST be present if any date/time refers to a Silverberg/Mansour/Daws/Hopson 26 Expires November 1998
timezone CONTACT 0+
VALARM MAY CREATED 0 or 1
DESCRIPTION 0 or 1
DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PRIORITY 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise it
MUST NOT be present.
RELATED-TO 0+
REQUEST-STATUS 0+
RESOURCES 0 or 1 This property may contain a list of values
RRULE 0+
STATUS 0 or 1 Value must be one of CONFIRMED/TENATIVE/
CANCELLED
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
X-TOKENS MAY VALARM 0+
VTODO NOT VTIMEZONE 0+ MUST be present if any date/time refers to
VJOURNAL NOT a timezone
VFREEBUSY NOT X-COMPONENT 0+
Silverberg/Mansour/Dawson/Hopson 25 Expires September 1998 VTODO 0
VJOURNAL 0
VFREEBUSY 0
3.2.8 DECLINECOUNTER 3.2.8 DECLINECOUNTER
The "DECLINE-COUNTER" method in a "VEVENT" calendar component is used by The "DECLINECOUNTER" method in a "VEVENT" calendar component is used by
the "Organizer" of an event to reject a counter proposal submitted by an the "Organizer" of an event to reject a counter proposal submitted by an
"Attendee". The "Organizer" must send the "DECLINE-COUNTER" message to "Attendee". The "Organizer" must send the "DECLINECOUNTER" message to
the "Attendee" that sent the "COUNTER" method to the "Organizer". the "Attendee" that sent the "COUNTER" method to the "Organizer".
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "DECLINECOUNTER"
VERSION MUST be "2.0"
METHOD MUST be "DECLINECOUNTER"
VEVENT MUST VEVENT 1
DTSTAMP MUST DTSTAMP 1
ORGANIZER MUST ORGANIZER 1
RECURRENCE-ID MUST only if referring to an instance of a UID 1 MUST, same UID specified in original
recurring calendar component. Otherwise it
must NOT be present.
SEQUENCE MUST if non-zero, MAY be present if zero
UID MUST, same UID specified in original
REQUEST and subsequent COUNTER REQUEST and subsequent COUNTER
COMMENT MAY Silverberg/Mansour/Daws/Hopson 27 Expires November 1998
REQUEST-STATUS MAY COMMENT 0 or 1
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
ATTACH NOT recurring calendar component. Otherwise it
ATTENDEE NOT MUST NOT be present.
CATEGORIES NOT REQUEST-STATUS 0+
CLASS NOT SEQUENCE 0 OR 1 MUST be present if value is greater than 0,
CONTACT NOT MAY be present if 0
CREATED NOT X-PROPERTY 0+
DESCRIPTION NOT
DTSTART NOT
DTEND NOT
DURATION NOT
EXDATE NOT
EXRULE NOT
GEO NOT
LAST-MODIFIED NOT
PRIORITY NOT
RDATE NOT
RELATED-TO NOT
RESOURCES NOT
RRULE NOT
STATUS NOT
SUMMARY NOT
TRANSP NOT
URL NOT
VTIMEZONE MUST be present if any date/time refers to a ATTACH 0
ATTENDEE 0
CATEGORIES 0
CLASS 0
CONTACT 0
CREATED 0
DESCRIPTION 0
DTEND 0
DTSTART 0
DURATION 0
EXDATE 0
EXRULE 0
GEO 0
LAST-MODIFIED 0
LOCATION 0
PRIORITY 0
RDATE 0
RELATED-TO 0
RESOURCES 0
RRULE 0
STATUS 0
SUMMARY 0
TRANSP 0
URL 0
Silverberg/Mansour/Dawson/Hopson 26 Expires September 1998 X-COMPONENT 0+
timezone VTODO 0
X-TOKENS MAY VJOURNAL 0
VTODO NOT VFREEBUSY 0
VJOURNAL NOT VTIMEZONE 0
VFREEBUSY NOT VALARM 0
VALARM NOT
3.3 Methods For VFREEBUSY Components 3.3 Methods For VFREEBUSY Components
This section defines the property set for the methods that are This section defines the property set for the methods that are
applicable to the "VFREEBUSY" calendar component. Each of the methods is applicable to the "VFREEBUSY" calendar component. Each of the methods is
defined using a restriction table. defined using a restriction table.
This document only addresses the transfer of busy time information. This document only addresses the transfer of busy time information.
Applications desiring free time information MUST infer this from Applications desiring free time information MUST infer this from
available busy time information. available busy time information.
Silverberg/Mansour/Daws/Hopson 28 Expires November 1998
The busy time information within the iCalendar object MAY be grouped The busy time information within the iCalendar object MAY be grouped
into more than one "VFREEBUSY" calendar component. This capability into more than one "VFREEBUSY" calendar component. This capability
allows busy time periods to be grouped according to some common allows busy time periods to be grouped according to some common
periodicity, such as a calendar week, month, or year. In this case, each periodicity, such as a calendar week, month, or year. In this case, each
"VFREEBUSY" calendar component MUST include the "ATTENDEE", "DTSTART" "VFREEBUSY" calendar component MUST include the "ATTENDEE", "DTSTART"
and "DTEND" properties in order to specify the source of the busy time and "DTEND" properties in order to specify the source of the busy time
information and the date and time interval over which the busy time information and the date and time interval over which the busy time
information covers. information covers.
The "FREEBUSY" property value MAY include a list of values, separated by The "FREEBUSY" property value MAY include a list of values, separated by
skipping to change at line 1354 skipping to change at line 1493
"B", "C" and "D". Individual "B" and "C" replies with busy time data to "B", "C" and "D". Individual "B" and "C" replies with busy time data to
individual "A". Individual "D" does not support busy time requests and individual "A". Individual "D" does not support busy time requests and
does not reply with any data. If the transport binding supports does not reply with any data. If the transport binding supports
exception messages, then individual "D" returns an "unsupported exception messages, then individual "D" returns an "unsupported
capability" message to individual "A". capability" message to individual "A".
The following summarizes the methods that are defined for the The following summarizes the methods that are defined for the
"VFREEBUSY" calendar component. "VFREEBUSY" calendar component.
|================|==================================================| |================|==================================================|
Silverberg/Mansour/Dawson/Hopson 27 Expires September 1998
| Method | Description | | Method | Description |
|================|==================================================| |================|==================================================|
| PUBLISH | Publish unsolicited busy time data. | | PUBLISH | Publish unsolicited busy time data. |
| REQUEST | Request busy time data. | | REQUEST | Request busy time data. |
| REPLY | Reply to a busy time request. | | REPLY | Reply to a busy time request. |
|================|==================================================| |================|==================================================|
3.3.1 PUBLISH 3.3.1 PUBLISH
The "PUBLISH" method in a "VFREEBUSY" calendar component is used to The "PUBLISH" method in a "VFREEBUSY" calendar component is used to
publish busy time data. The method may be sent from one CU to any other. publish busy time data. The method may be sent from one CU to any other.
The purpose of the method is to provide a message for sending The purpose of the method is to provide a message for sending
unsolicited busy time data. That is, the busy time data is not being unsolicited busy time data. That is, the busy time data is not being
sent as a "REPLY" to the receipt of a "REQUEST" method. sent as a "REPLY" to the receipt of a "REQUEST" method.
The "ATTENDEE" property must be specified in the busy time information. The "ATTENDEE" property must be specified in the busy time information.
The value is the CU address of the originator of the busy time The value is the CU address of the originator of the busy time
information. information.
Silverberg/Mansour/Daws/Hopson 29 Expires November 1998
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "PUBLISH"
VERSION MUST be "2.0"
METHOD MUST be "PUBLISH"
VFREEBUSY MUST VFREEBUSY 1+
ATTENDEE MUST contain the address of originator of DTSTAMP 1
busy time data DTSTART 1 DateTime values must be in UTC
DTSTAMP MUST DTEND 1 DateTime values must be in UTC
FREEBUSY MUST be BUSYTIME. Multiple instances are allowed. FREEBUSY 1+ MUST be BUSYTIME. Multiple instances are
Multiple instances must be sorted in ascending allowed. Multiple instances must be sorted
order. in ascending order
ATTACH MAY ORGANIZER 1 MUST contain the address of originator of
RELATED-TO MAY busy time data.
COMMENT MAY
CONTACT MAY
CREATED MAY specifies when the busy time data was
Created
DTSTART MAY be present to represent start of the
interval for busy time data
DTEND MAY be present to represent the end of
the interval for busy time data
GEO MAY
ORGANIZER MAY
URL MAY (specifies busy time URL)
CATEGORIES NOT COMMENT 0 or 1
CLASS NOT CONTACT 0+
DESCRIPTION NOT X-PROPERTY 0+
URL 0 or 1 Specifies busy time URL
Silverberg/Mansour/Dawson/Hopson 28 Expires September 1998 ATTENDEE 0
DURATION NOT DURATION 0
EXDATE NOT REQUEST-STATUS 0
EXRULE NOT UID 0
LAST-MODIFIED NOT
PRIORITY NOT
RDATE NOT
RECURRENCE-ID NOT
REQUEST-STATUS NOT
RESOURCES NOT
RRULE NOT
SEQUENCE NOT
STATUS NOT
SUMMARY NOT
TRANSP NOT
UID NOT
VTIMEZONE MUST be present if any date/time refers to a X-COMPONENT 0+
timezone
X-TOKENS NOT VEVENT 0
VEVENT NOT VTODO 0
VTODO NOT VJOURNAL 0
VJOURNAL NOT VTIMEZONE 0
VALARM NOT VALARM 0
3.3.2 REQUEST 3.3.2 REQUEST
The "REQUEST" method in a "VFREEBUSY" calendar component is used to ask The "REQUEST" method in a "VFREEBUSY" calendar component is used to ask
a "Calendar User" for their busy time information. The request may be a "Calendar User" for their busy time information. The request may be
for a busy time information bounded by a specific date and time for a busy time information bounded by a specific date and time
interval. interval.
This message only permits requests for busy time information. The This message only permits requests for busy time information. The
message is sent from a "Calendar User" requesting the busy time message is sent from a "Calendar User" requesting the busy time
information to one or more intended recipients. information to one or more intended recipients.
If the originator of the "REQUEST" method is not authorized to make a If the originator of the "REQUEST" method is not authorized to make a
busy time request on the recipient's calendar system, then an exception busy time request on the recipient's calendar system, then an exception
message SHOULD be returned in a "REPLY" method, but no busy time data message SHOULD be returned in a "REPLY" method, but no busy time data
need be returned. need be returned.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Silverberg/Mansour/Daws/Hopson 30 Expires November 1998
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "REQUEST"
VERSION MUST be "2.0"
METHOD MUST be "REQUEST"
VFREEBUSY MUST VFREEBUSY 1
ATTENDEE MUST contain the address of the calendar store ATTENDEE 1+ contain the address of the calendar store
for which busy time is being requested. for which busy time is being requested.
DTEND 1 DateTime values must be in UTC
DTSTAMP 1
DTSTART 1 DateTime values must be in UTC
ORGANIZER 1 MUST be the request originator's address
UID 1
COMMENT 0 or 1
CONTACT 0+
X-PROPERTY 0+
Silverberg/Mansour/Dawson/Hopson 29 Expires September 1998 FREEBUSY 0
DTEND MUST DURATION 0
DTSTAMP MUST REQUEST-STATUS 0
DTSTART MUST URL 0
ORGANIZER MUST be the request originator's address
ATTACH MAY
COMMENT MAY
CONTACT MAY
GEO MAY
URL MAY
CATEGORIES NOT
CLASS NOT
CREATED NOT
DESCRIPTION NOT
DURATION NOT
EXDATE NOT
EXRULE NOT
FREEBUSY NOT
LAST-MODIFIED NOT
PRIORITY NOT
RDATE NOT
RECURRENCE-ID NOT
RELATED-TO NOT
REQUEST-STATUS NOT
RESOURCES NOT
RRULE NOT
SEQUENCE NOT
STATUS NOT
SUMMARY NOT
TRANSP NOT
UID NOT
VTIMEZONE MUST be present if any date/time refers to a
X-TOKENS MAY X-COMPONENT 0+
VEVENT NOT VALARM 0
VTODO NOT VEVENT 0
VJOURNAL NOT VTODO 0
VALARM NOT VJOURNAL 0
VTIMEZONE 0
3.3.3 REPLY 3.3.3 REPLY
The "REPLY" method in a "VFREEBUSY" calendar component is used to The "REPLY" method in a "VFREEBUSY" calendar component is used to
respond to a busy time request. The method is sent by the recipient of a respond to a busy time request. The method is sent by the recipient of a
busy time request to the originator of the request. busy time request to the originator of the request.
The "REPLY" method may also be used to respond to an unsuccessful The "REPLY" method may also be used to respond to an unsuccessful
"REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy time "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy time
information may be returned. information may be returned.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Silverberg/Mansour/Dawson/Hopson 30 Expires September 1998
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "REPLY"
VERSION MUST be "2.0"
METHOD MUST be "REPLY"
VFREEBUSY MUST VFREEBUSY 1
ATTENDEE MUST (address of recipient replying) ATTENDEE 1 (address of recipient replying)
DTSTAMP MUST DTSTAMP 1
DTSTART MUST DTEND 1 DateTime values must be in UTC
DTEND MUST DTSTART 1 DateTime values must be in UTC
FREEBUSY MUST (values MUST all be of the same data FREEBUSY 1+ (values MUST all be of the same data
Silverberg/Mansour/Daws/Hopson 31 Expires November 1998
type. Multiple instances are allowed. type. Multiple instances are allowed.
Multiple instances MUST be sorted in Multiple instances MUST be sorted in
ascending order. Values MAY NOT overlap) ascending order. Values MAY NOT overlap)
ORGANIZER MUST be the request originator's address ORGANIZER 1 MUST be the request originator's address
RECURRENCE-ID MUST only if referring to an instance of a UID 1
recurring calendar component. Otherwise it
must NOT be present.
UID MUST
ATTACH MAY
COMMENT MAY
CONTACT MAY
CREATED MAY specifies when the busy time data was
created)
DTSTART MAY (represents start of interval for busy
time data}, DTEND{represents end of
interval for busy time data)
GEO MAY
RELATED-TO MAY
REQUEST-STATUS MAY
SEQUENCE MAY be present if non-zero
URL MAY (specifies busy time URL)
CATEGORIES NOT
CLASS NOT
DESCRIPTION NOT
DURATION NOT
EXDATE NOT
EXRULE NOT
FREEBUSY NOT
LAST-MODIFIED NOT
PRIORITY NOT
RDATE NOT
RESOURCES NOT
RRULE NOT
SEQUENCE NOT
STATUS NOT
SUMMARY NOT
TRANSP NOT
VTIMEZONE MUST be present if any date/time refers to a
Silverberg/Mansour/Dawson/Hopson 31 Expires September 1998 COMMENT 0 or 1
timezone CONTACT 0+
REQUEST-STATUS 0+
URL 0 or 1 (specifies busy time URL)
X-PROPERTY 0+
DURATION 0
SEQUENCE 0
X-TOKENS MAY X-COMPONENT 0+
VEVENT NOT VALARM 0
VTODO NOT VEVENT 0
VJOURNAL NOT VTODO 0
VALARM NOT VJOURNAL 0
VTIMEZONE 0
3.4 Methods For VTODO Components 3.4 Methods For VTODO Components
This section defines the property set for the methods that are This section defines the property set for the methods that are
applicable to the "VTODO" calendar component. Each of the methods is applicable to the "VTODO" calendar component. Each of the methods is
defined using a restriction table that specifies the property defined using a restriction table that specifies the property
constraints that define the particular method. constraints that define the particular method.
The following summarizes the methods that are defined for the "VTODO" The following summarizes the methods that are defined for the "VTODO"
calendar component. calendar component.
skipping to change at line 1607 skipping to change at line 1665
| PUBLISH | Post notification of a VTODO. Used primarily as | | PUBLISH | Post notification of a VTODO. Used primarily as |
| | a method of advertising the existence of a VTODO.| | | a method of advertising the existence of a VTODO.|
| | | | | |
| REQUEST | Assign a VTODO. This is an explicit assignment to| | REQUEST | Assign a VTODO. This is an explicit assignment to|
| | one or more Calendar Users. The REQUEST method | | | one or more Calendar Users. The REQUEST method |
| | is also used to update or change an existing | | | is also used to update or change an existing |
| | VTODO. Clients that cannot handle REQUEST MAY | | | VTODO. Clients that cannot handle REQUEST MAY |
| | degrade the method to treat it as a PUBLISH. | | | degrade the method to treat it as a PUBLISH. |
| | | | | |
| REPLY | Reply to a VTODO request. Attendees MAY set | | REPLY | Reply to a VTODO request. Attendees MAY set |
| | ATTSTAT to ACCEPTED, DECLINED, TENTATIVE, | | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, |
| | DELEGATED, PARTIAL, and COMPLETED. | | | DELEGATED, PARTIAL, and COMPLETED. |
| | | | | |
| ADD | Add one or more instances to an existing to-do. | | ADD | Add one or more instances to an existing to-do. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | to-do. | | | to-do. |
| | | | | |
| REFRESH | A request sent to a VTODO "Organizer" asking for |
Silverberg/Mansour/Daws/Hopson 32 Expires November 1998
| REFRESH | A request sent to a VTODO Organizer asking for |
| | the latest version of a VTODO. | | | the latest version of a VTODO. |
| | | | | |
| COUNTER | Counter a REQUEST with an alternative proposal. | | COUNTER | Counter a REQUEST with an alternative proposal. |
| | | | | |
| DECLINECOUNTER | Decline a counter proposal by an "Attendee." | | DECLINECOUNTER | Decline a counter proposal by an Attendee. |
+================+==================================================+ +================+==================================================+
Silverberg/Mansour/Dawson/Hopson 32 Expires September 1998
3.4.1 PUBLISH 3.4.1 PUBLISH
The "PUBLISH" method in a "VTODO" calendar component has no associated The "PUBLISH" method in a "VTODO" calendar component has no associated
response. It is simply a posting of an iCalendar object that maybe added response. It is simply a posting of an iCalendar object that maybe added
to a calendar by a "Calendar User". Its expected usage is for to a calendar. It MUST have an "Organizer". It MUST NOT have
encapsulating an arbitrary "VTODO" calendar component as an iCalendar "Attendees". Its expected usage is for encapsulating an arbitrary
object. The "Organizer" MAY subsequently update (with another "PUBLISH" "VTODO" calendar component as an iCalendar object. The "Organizer" MAY
method), add instances to (win an "ADD" method), or cancel (with a subsequently update (with another "PUBLISH" method), add instances to
"CANCEL" method) a previously published "VTODO" calendar component. (win an "ADD" method), or cancel (with a "CANCEL" method) a previously
published "VTODO" calendar component.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "PUBLISH"
VERSION MUST be "2.0" VTODO 1+
METHOD MUST be "PUBLISH" DTSTAMP 1
VTODO MUST DTSTART 1
DTSTAMP MUST ORGANIZER 1
DTSTART MUST PRIORITY 1
ORGANIZER MUST SEQUENCE 0 or 1 MUST be present if value is greater than
RECURRENCE-ID MUST only if referring to an instance of a 0, MAY be present if 0
recurring calendar component. Otherwise it SUMMARY 1 Can be null.
must NOT be present. UID 1
SEQUENCE MUST be present if not 0, may be present if 0
SUMMARY MUST; may be null.
UID MUST
ATTENDEE MAY ATTACH 0+
ATTACH MAY CATEGORIES 0 or 1 This property may contain a list of values
CATEGORIES MAY CLASS 0 or 1
CLASS MAY COMMENT 0 or 1
COMMENT MAY CONTACT 0+
CONTACT MAY CREATED 0 or 1
CREATED MAY DESCRIPTION 0 or 1 Can be null
DESCRIPTION MAY be present and MAY be NULL DUE 0 or 1 If present DURATION MUST NOT be present
DURATION MAY DURATION 0 or 1 If present DUE MUST NOT be present
DTEND MAY EXDATE 0+
EXDATE MAY EXRULE 0+
EXRULE MAY GEO 0 or 1
GEO MAY LAST-MODIFIED 0 or 1
LAST-MODIFIED MAY LOCATION 0 or 1
LOCATION MAY PERCENT-COMPLETE 0 or 1
PERCENT-COMPLETE MAY RDATE 0+
PRIORITY MAY RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
RELATED-TO MAY
RDATE MAY
RESOURCES MAY
RRULE MAY
STATUS MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS
TRANSP MAY
URL MAY
Silverberg/Mansour/Dawson/Hopson 33 Expires September 1998 Silverberg/Mansour/Daws/Hopson 33 Expires November 1998
recurring calendar component. Otherwise
it MUST NOT be present.
VEVENT NOT RELATED-TO 0+
VJOURNAL NOT RESOURCES 0 or 1 This property may contain a list of values
VTIMEZONE MUST be present if any date/time refers to a RRULE 0+
timezone STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
VALARM MAY PROCESS/CANCELLED
VFREEBUSY NOT URL 0 or 1
X-TOKENS MAY X-PROPERTY 0+
ATTENDEE 0
REQUEST-STATUS 0
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
VALARM 0+
X-COMPONENT 0+
VFREEBUSY 0
VEVENT 0
VJOURNAL 0
3.4.2 REQUEST 3.4.2 REQUEST
The "REQUEST" method in a "VTODO" calendar component provides the The "REQUEST" method in a "VTODO" calendar component provides the
following scheduling functions: following scheduling functions:
. Assign a to-do to one or more "Calendar Users"; . Assign a to-do to one or more "Calendar Users";
. Reschedule an existing to-do; . Reschedule an existing to-do;
. Update the details of an existing to-do, without rescheduling it; . Update the details of an existing to-do, without rescheduling it;
. Update the completion status of "Attendees" of an existing to-do, . Update the completion status of "Attendees" of an existing to-do,
without rescheduling it; without rescheduling it;
. Reconfirm an existing to-do, without rescheduling it; . Reconfirm an existing to-do, without rescheduling it;
. Delegate/reassign an existing to-do to another "Calendar User". . Delegate/reassign an existing to-do to another "Calendar User".
The assigned "Calendar Users" are identified in the "VTODO" calendar The assigned "Calendar Users" are identified in the "VTODO" calendar
component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property value component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property value
sequences. sequences.
The originator of a "REQUEST" is the "Organizer" of the to-do. The The originator of a "REQUEST" is the "Organizer" of the to-do. The
recipient of a "REQUEST" is the "Calendar User" assigned the to-do-the recipient of a "REQUEST" is the "Calendar User" assigned the to-do. The
"Attendee". The "Attendee" uses the "REPLY" method to convey their "Attendee" uses the "REPLY" method to convey their acceptance and
acceptance and completion status to the "Organizer" of the "REQUEST". completion status to the "Organizer" of the "REQUEST".
The "UID", "SEQUENCE", and "DTSTAMP" properties are used to distinguish The "UID", "SEQUENCE", and "DTSTAMP" properties are used to distinguish
the various uses of the "REQUEST" method. If the "UID" property value in the various uses of the "REQUEST" method. If the "UID" property value in
the "REQUEST" is not found on the recipient's calendar, then the the "REQUEST" is not found on the recipient's calendar, then the
"REQUEST" is for a new to-do. If the "UID" property value is found on "REQUEST" is for a new to-do. If the "UID" property value is found on
the recipient's calendar, then the "REQUEST" is a rescheduling, an the recipient's calendar, then the "REQUEST" is a rescheduling, an
update, or a reconfirm of the "VTODO" calendar object. update, or a reconfirm of the "VTODO" calendar object.
Silverberg/Mansour/Daws/Hopson 34 Expires November 1998
If the "Organizer" of the "REQUEST" method is not authorized to make a If the "Organizer" of the "REQUEST" method is not authorized to make a
to-do request on the "Attendee's" calendar system, then an exception is to-do request on the "Attendee's" calendar system, then an exception is
returned in the "REQUEST-STATUS" property of a subsequent "REPLY" returned in the "REQUEST-STATUS" property of a subsequent "REPLY"
method, but no scheduling action is performed. method, but no scheduling action is performed.
For the "REQUEST" method, multiple "VTODO" components in a single
iCalendar object are only permitted when for components with the same
"UID" property. That is, a series of recurring events may have
instance-specific information. In this case, multiple "VTODO"
components are needed to express the entire series.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "REQUEST"
VERSION MUST be "2.0" VTODO 1+ All components must have the same UID
METHOD MUST be "REQUEST" ATTENDEE 1+
DTSTAMP 1
DTSTART 1
ORGANIZER 1
PRIORITY 1
SEQUENCE 0 or 1 MUST be present if value is greater than
0, MAY be present if 0
SUMMARY 1 Can be null.
UID 1
Silverberg/Mansour/Dawson/Hopson 34 Expires September 1998 ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of
values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 present if referring to an instance of a
recurring calendar component. Otherwise
it MUST NOT be present.
RELATED-TO 0+
RESOURCES 0 or 1 This property may contain a list of
values
RRULE 0+
STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
VTODO MUST Silverberg/Mansour/Daws/Hopson 35 Expires November 1998
ATTENDEE MUST PROCESS
DTSTAMP MUST URL 0 or 1
DTSTART MUST X-PROPERTY 0+
ORGANIZER MUST
RECURRENCE-ID MUST only if referring to an instance of a
recurring calendar component. Otherwise it
must NOT be present.
SEQUENCE MUST be present if not 0, may be present if 0
SUMMARY MUST; may be null.
UID MUST
ATTACH MAY
CATEGORIES MAY
CLASS MAY
COMMENT MAY
CONTACT MAY
CREATED MAY
DESCRIPTION MAY be present and MAY be NULL
DURATION MAY
DTEND MAY
EXDATE MAY
EXRULE MAY
GEO MAY
LAST-MODIFIED MAY
LOCATION MAY
PERCENT-COMPLETE MAY
PRIORITY MAY
RELATED-TO MAY
RDATE MAY
RESOURCES MAY
RRULE MAY
STATUS MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS
TRANSP MAY
URL MAY
VEVENT NOT REQUEST-STATUS 0
VJOURNAL NOT
VTIMEZONE MUST be present if any date/time refers to a VALARM 0+
timezone VTIMEZONE 0+ MUST be present if any date/time refers
VALARM MAY to a timezone
VFREEBUSY NOT X-COMPONENT 0+
X-TOKENS MAY
VEVENT 0
VFREEBUSY 0
VJOURNAL 0
3.4.2.1 REQUEST for Rescheduling a VTODO 3.4.2.1 REQUEST for Rescheduling a VTODO
The "REQUEST" method may be used to reschedule a "VTODO" calendar The "REQUEST" method may be used to reschedule a "VTODO" calendar
component. component.
Rescheduling a "VTODO" calendar component involves a change to the Rescheduling a "VTODO" calendar component involves a change to the
existing "VTODO" calendar component in terms of its start or due time or existing "VTODO" calendar component in terms of its start or due time or
recurrence intervals and possibly the description. If the recipient CUA recurrence intervals and possibly the description. If the recipient CUA
of a "REQUEST" method finds that the "UID" property value already exists of a "REQUEST" method finds that the "UID" property value already exists
on the calendar, but that the "SEQUENCE" property value in the "REQUEST" on the calendar, but that the "SEQUENCE" property value in the "REQUEST"
Silverberg/Mansour/Dawson/Hopson 35 Expires September 1998
is greater than the value for the existing VTODO, then the "REQUEST" is greater than the value for the existing VTODO, then the "REQUEST"
method describes a rescheduling of the "VTODO" calendar component. method describes a rescheduling of the "VTODO" calendar component.
3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO 3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO
The "REQUEST" method may be used to update or reconfirm a "VTODO" The "REQUEST" method may be used to update or reconfirm a "VTODO"
calendar component. Reconfirmation is merely an update of "Attendee" calendar component. Reconfirmation is merely an update of "Attendee"
completion status or overall "VTODO" calendar component status. completion status or overall "VTODO" calendar component status.
An update to an existing "VTODO" calendar component does not involve An update to an existing "VTODO" calendar component does not involve
skipping to change at line 1818 skipping to change at line 1890
The update "REQUEST" is the appropriate response to a "REFRESH" method The update "REQUEST" is the appropriate response to a "REFRESH" method
sent from an "Attendee" to the "Organizer" of a "VTODO" calendar sent from an "Attendee" to the "Organizer" of a "VTODO" calendar
component. component.
Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a
"VTODO" calendar component. The unsolicited "REQUEST" methods are used "VTODO" calendar component. The unsolicited "REQUEST" methods are used
to update the details of the "VTODO" (without rescheduling it or to update the details of the "VTODO" (without rescheduling it or
updating the completion status of "Attendees") or the "VTODO" calendar updating the completion status of "Attendees") or the "VTODO" calendar
component itself (i.e., reconfirm the "VTODO"). component itself (i.e., reconfirm the "VTODO").
Silverberg/Mansour/Daws/Hopson 36 Expires November 1998
3.4.2.3 REQUEST for Delegating a VTODO 3.4.2.3 REQUEST for Delegating a VTODO
The "REQUEST" method is also used to delegate or reassign ownership of a The "REQUEST" method is also used to delegate or reassign ownership of a
"VTODO" calendar component to another "Calendar User". For example, it "VTODO" calendar component to another "Calendar User". For example, it
may be used to delegate an "Attendee's" role (i.e. "chair", or may be used to delegate an "Attendee's" role (i.e. "chair", or
"participant") for a "VTODO" calendar component. The "REQUEST" method is "participant") for a "VTODO" calendar component. The "REQUEST" method is
sent by one of the "Attendees" of an existing "VTODO" calendar component sent by one of the "Attendees" of an existing "VTODO" calendar component
to some other individual. An "Attendee" of a "VTODO" calendar component to some other individual. An "Attendee" of a "VTODO" calendar component
MUST NOT delegate to the "Organizer" of the event. MUST NOT delegate to the "Organizer" of the event.
skipping to change at line 1840 skipping to change at line 1913
"Attendee" receiving the delegation request is referred to as the "Attendee" receiving the delegation request is referred to as the
"Delegate". "Delegate".
The "Delegator" of a "VTODO" calendar component MUST forward the The "Delegator" of a "VTODO" calendar component MUST forward the
existing "REQUEST" method for a "VTODO" calendar component to the existing "REQUEST" method for a "VTODO" calendar component to the
"Delegate". The "VTODO" calendar component description MUST include the "Delegate". The "VTODO" calendar component description MUST include the
"Delegator's" up-to-date "VTODO" calendar component definition. The "Delegator's" up-to-date "VTODO" calendar component definition. The
"REQUEST" method MUST also include an "ATTENDEE" property with the "REQUEST" method MUST also include an "ATTENDEE" property with the
calendar address of the "Delegate". The "Delegator" MUST also send a calendar address of the "Delegate". The "Delegator" MUST also send a
"REPLY" method back to the "Organizer" with the "Delegator's" "Attendee" "REPLY" method back to the "Organizer" with the "Delegator's" "Attendee"
property "attstat" parameter value set to "DELEGATED". In addition, the property "partstat" parameter value set to "DELEGATED". In addition, the
"delegated-to" parameter SHOULD be included with the calendar address of "delegated-to" parameter MUST be included with the calendar address of
Silverberg/Mansour/Dawson/Hopson 36 Expires September 1998
the "Delegate". A response to the delegation "REQUEST" is sent from the the "Delegate". A response to the delegation "REQUEST" is sent from the
"Delegate" to the "Organizer" and optionally, to the "Delegator". The "Delegate" to the "Organizer" and optionally, to the "Delegator". The
"REPLY" method from the "Delegate" SHOULD include the "ATTENDEE" "REPLY" method from the "Delegate" SHOULD include the "ATTENDEE"
property with their calendar address and the "delegated-from" parameter property with their calendar address and the "delegated-from" parameter
with the value of the "Delegator's" calendar address. with the value of the "Delegator's" calendar address.
The delegation "REQUEST" method MUST assign a value for the "RSVP" The delegation "REQUEST" method MUST assign a value for the "RSVP"
property parameter associated with the "Delegator's" "Attendee" property property parameter associated with the "Delegator's" "Attendee" property
to that of the "Delegate's" "ATTENDEE" property. For example if the to that of the "Delegate's" "ATTENDEE" property. For example if the
"Delegator's" "ATTENDEE" property specifies "RSVP=TRUE", then the "Delegator's" "ATTENDEE" property specifies "RSVP=TRUE", then the
"Delegate's" "ATTENDEE" property MUST specify "RSVP=TRUE". "Delegate's" "ATTENDEE" property MUST specify "RSVP=TRUE".
3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User 3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User
An "Attendee" assigned a "VTODO" calendar component may assign the An "Attendee" assigned a "VTODO" calendar component may send the "VTODO"
"VTODO" calendar component to another new "Calendar User", not calendar component to another new CU, not previously associated with the
previously associated with the "VTODO" calendar component. The current "VTODO" calendar component. The current "Attendee" assigned the "VTODO"
"Attendee" assigned the "VTODO" calendar component accomplishes this calendar component does this by forwarding the original "REQUEST" method
scheduling action by forwarding the original "REQUEST" method to the new to the new CU. The new CU can send a "REPLY" to the "Organizer" of the
"Calendar User". "VTODO" calendar component. The reply contains an "ATTENDEE" property
for the new CU.
The "Organizer" ultimately decides whether or not the new CU becomes
part of the to-do and is not obligated to do anything with a "REPLY"
from a new (uninvited) CU. If the "Organizer" does not want the new CU
to be part of the to-do, the new "ATTENDEE" property is not added to the
"VTODO" calendar component. The "Organizer" MAY send the CU a "CANCEL"
message to indicate that they will not be added to the to-do. If the
"Organizer" decides to add the new CU, the new "ATTENDEE" property is
Silverberg/Mansour/Daws/Hopson 37 Expires November 1998
added to the "VTODO" calendar component. Furthermore, the "Organizer" is
free to change any "ATTENDEE" property parameter from the values
supplied by the new CU to something the "Organizer" considers
appropriate.
3.4.2.5 REQUEST Updated Attendee Status 3.4.2.5 REQUEST Updated Attendee Status
An "Organizer" of a "VTODO" may request an updated status from one or An "Organizer" of a "VTODO" may request an updated status from one or
more "Attendees". The "Organizer" sends a "REQUEST" method to the more "Attendees". The "Organizer" sends a "REQUEST" method to the
"Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The
"SEQUENCE" property for the "VTODO" is not changed from its previous "SEQUENCE" property for the "VTODO" is not changed from its previous
value. A recipient determines that the only change in the "REQUEST" is value. A recipient determines that the only change in the "REQUEST" is
that their "RSVP" property parameter indicates a request for an updated that their "RSVP" property parameter indicates a request for an updated
status. The recipient SHOULD respond with a "REPLY" method indicating status. The recipient SHOULD respond with a "REPLY" method indicating
their current status with respect to the "REQUEST". their current status with respect to the "REQUEST".
3.4.3 REPLY 3.4.3 REPLY
The "REPLY" method in a "VTODO" calendar component is used to respond The "REPLY" method in a "VTODO" calendar component is used to respond
(e.g., accept or decline) to a request or to reply to a delegation (e.g., accept or decline) to a request or to reply to a delegation
request. It is also used by an "Attendee" to update their completion request. It is also used by an "Attendee" to update their completion
status. When used to provide a delegation response, the "Delegator" status. When used to provide a delegation response, the "Delegator" MUST
SHOULD include the calendar address of the "Delegate" in the "delegated- include the calendar address of the "Delegate" in the "delegated-to"
to" parameter of the "Delegator's" "ATTENDEE" property. The "Delegate" parameter of the "Delegator's" "ATTENDEE" property. The "Delegate" MUST
SHOULD include the calendar address of the "Delegator" on the include the calendar address of the "Delegator" on the "delegated-from"
"delegated-from" parameter of the "Delegate's" "ATTENDEE" property. parameter of the "Delegate's" "ATTENDEE" property.
The "REPLY" method MAY also be used to respond to an unsuccessful The "REPLY" method MAY also be used to respond to an unsuccessful
"VTODO" calendar component "REQUEST" method. Depending on the "REQUEST- "VTODO" calendar component "REQUEST" method. Depending on the "REQUEST-
STATUS" value, no scheduling action may have been performed. STATUS" value, no scheduling action may have been performed.
The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY"
method from a "Calendar User" not in the original "REQUEST". For method from a "Calendar User" not in the original "REQUEST". For
example, a "REPLY" method MAY be received from a "Delegate" of a "VTODO" example, a "REPLY" method MAY be received from a "Delegate" of a "VTODO"
calendar component. In addition, the "REPLY" method MAY be received from calendar component. In addition, the "REPLY" method MAY be received from
Silverberg/Mansour/Dawson/Hopson 37 Expires September 1998
an unknown "Calendar User", having been forwarded the "REQUEST" by an an unknown "Calendar User", having been forwarded the "REQUEST" by an
original "Attendee" of the "VTODO" calendar component. This uninvited original "Attendee" of the "VTODO" calendar component. This uninvited
"Attendee" MAY be accepted, or the "Organizer" MAY cancel the "VTODO" "Attendee" MAY be accepted, or the "Organizer" MAY cancel the "VTODO"
calendar component for the uninvited "Attendee" by sending them a calendar component for the uninvited "Attendee" by sending them a
"CANCEL" method. "CANCEL" method.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- --------------------------------------------- ------------------- ---------------------------------------------
PRODID MUST METHOD 1 MUST be "REPLY"
VERSION MUST be "2.0" VTODO 1+ All component MUST have the same UID
METHOD MUST be "REPLY" ATTENDEE 1+
VTODO MUST DTSTAMP 1
ATTENDEE MUST ORGANIZER 1
UID MUST must be the address of the replying attendee
DTSTAMP MUST
ORGANIZER MUST
RECURRENCE-ID MUST only if referring to an instance of a
Recurring calendar component. Otherwise it
Must NOT be present
SEQUENCE MUST
COMMENT MAY Silverberg/Mansour/Daws/Hopson 38 Expires November 1998
PERCENT-COMPLETE MAY REQUEST-STATUS 1+
REQUEST-STATUS MAY UID 1 MUST must be the address of the replying
attendee
DTSTART NOT ATTACH 0+
CREATED NOT CATEGORIES 0 or 1 This property may contain a list of values
DESCRIPTION NOT CLASS 0 or 1
PRIORITY NOT COMMENT 0 or 1
CLASS NOT CONTACT 0+
CATEGORIES NOT CREATED 0 or 1
CONTACT NOT DESCRIPTION 0 or 1
CREATED NOT DTSTART 0 or 1
DTEND NOT DUE 0 or 1 If present DURATION MUST NOT be present
GEO NOT DURATION 0 or 1 If present DUE MUST NOT be present
LAST-MODIFIED NOT EXDATE 0+
LOCATION NOT EXRULE 0+
RDATE NOT GEO 0 or 1
RRULE NOT LAST-MODIFIED 0 or 1
RELATED-TO NOT LOCATION 0 or 1
RESOURCE NOT PERCENT-COMPLETE 0 or 1
STATUS NOT PRIORITY 0 or 1
TRANSP NOT RDATE 0+
URL NOT RELATED-TO 0+
VTIMEZONE MUST be present if any date/time refers to a RESOURCES 0 or 1 This property may contain a list of values
timezone RRULE 0+
VALARM NOT RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
VEVENT NOT Recurring calendar component. Otherwise it
VFREEBUSY NOT MUST NOT be present
X-TOKENS NOT SEQUENCE 0 or 1 MUST be the sequence number of
the original REQUEST if greater than 0.
MAY be present if 0.
STATUS 0 or 1
SUMMARY 0 or 1 Can be null
URL 0 or 1
X-PROPERTY 0+
Silverberg/Mansour/Dawson/Hopson 38 Expires September 1998 VTIMEZONE 0 or 1 MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VALARM 0
VEVENT 0
VFREEBUSY 0
3.4.4 ADD 3.4.4 ADD
The "ADD" method in a "VTODO" calendar component is used to add one or The "ADD" method in a "VTODO" calendar component is used to add one or
more instances to an existing to-do. more instances to an existing to-do.
If the "UID" property value in the "ADD" is not found on the recipient's If the "UID" property value in the "ADD" is not found on the recipient's
calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer"
in order to be updated with the latest version of the "VTODO". If an in order to be updated with the latest version of the "VTODO". If an
"Attendee" implementation does not support the "ADD" method it should "Attendee" implementation does not support the "ADD" method it should
respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH". respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH".
Silverberg/Mansour/Daws/Hopson 39 Expires November 1998
The "SEQUENCE" property value is incremented as the sequence of to-dos
has changed.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "ADD"
VERSION MUST be "2.0" VTODO 1
METHOD MUST be "ADD" DTSTAMP 1
VTODO MUST ORGANIZER 1
DTSTAMP MUST PRIORITY 1
DTSTART MUST SEQUENCE 1 MUST be greater than 0
ORGANIZER MUST SUMMARY 1 Can be null.
SEQUENCE MUST be greater than 0 UID 1 MUST match that of the original to-do
SUMMARY MUST; may be null.
UID MUST match that of the original to-do
ATTENDEE MAY ATTACH 0+
ATTACH MAY ATTENDEE 0+
CATEGORIES MAY CATEGORIES 0 or 1 This property may contain a list of
CLASS MAY values
COMMENT MAY CLASS 0 or 1
CONTACT MAY COMMENT 0 or 1
CREATED MAY CONTACT 0+
DESCRIPTION MAY be present and MAY be NULL CREATED 0 or 1
DTEND MAY DESCRIPTION 0 or 1 Can be null
DURATION MAY DTSTART 0 or 1
EXDATE MAY DUE 0 or 1 If present DURATION MUST NOT be present
EXRULE MAY DURATION 0 or 1 If present DUE MUST NOT be present
GEO MAY EXDATE 0+
LAST-MODIFIED MAY EXRULE 0+
LOCATION MAY GEO 0 or 1
PERCENT-COMPLETE MAY LAST-MODIFIED 0 or 1
PRIORITY MAY LOCATION 0 or 1
RELATED-TO MAY PERCENT-COMPLETE 0 or 1
RDATE MAY RDATE 0+
RESOURCES MAY RELATED-TO 0+
RRULE MAY RESOURCES 0 or 1 This property may contain a list of
STATUS MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS values
TRANSP MAY RRULE 0+
URL MAY STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
PROCESS
URL 0 or 1
X-PROPERTY 0+
Silverberg/Mansour/Dawson/Hopson 39 Expires September 1998 RECURRENCE-ID 0
RECURRENCE-ID NOT REQUEST-STATUS 0
REQUEST-STATUS NOT
VEVENT NOT VALARM 0+
VJOURNAL NOT VTIMEZONE 0+ MUST be present if any date/time refers
VTIMEZONE MUST be present if any date/time refers to a to a timezone
timezone X-COMPONENT 0+
VALARM MAY
VFREEBUSY NOT VEVENT 0
X-TOKENS MAY
Silverberg/Mansour/Daws/Hopson 40 Expires November 1998
VJOURNAL 0
VFREEBUSY 0
3.4.5 CANCEL 3.4.5 CANCEL
The "CANCEL" method in a "VTODO" calendar component is used to send a The "CANCEL" method in a "VTODO" calendar component is used to send a
cancellation notice of an existing "VTODO" calendar request to the cancellation notice of an existing "VTODO" calendar request to the
"Attendees". The message is sent by the "Organizer" of a "VTODO" "Attendees". The message is sent by the "Organizer" of a "VTODO"
calendar component to the "Attendees" of the "VTODO" calendar component. calendar component to the "Attendees" of the "VTODO" calendar component.
For a recurring "VTODO" calendar component, either the whole "VTODO" For a recurring "VTODO" calendar component, either the whole "VTODO"
calendar component or instances of a "VTODO" calendar component may be calendar component or instances of a "VTODO" calendar component may be
cancelled. To cancel the complete range of a recurring "VTODO" calendar cancelled. To cancel the complete range of a recurring "VTODO" calendar
skipping to change at line 2047 skipping to change at line 2142
(a) the "RECURRENCE-ID" property for an instance in the sequence MUST be (a) the "RECURRENCE-ID" property for an instance in the sequence MUST be
specified with the "RANGE" property parameter value of THISANDPRIOR specified with the "RANGE" property parameter value of THISANDPRIOR
(or THISANDFUTURE) to indicate cancellation of the specified "VTODO" (or THISANDFUTURE) to indicate cancellation of the specified "VTODO"
calendar component and all instances before (or after); or calendar component and all instances before (or after); or
(b) individual recurrence instances may be cancelled by specifying (b) individual recurrence instances may be cancelled by specifying
multiple "RECURRENCE-ID" properties corresponding to the instances to multiple "RECURRENCE-ID" properties corresponding to the instances to
be cancelled. be cancelled.
When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
incremented.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- --------------------------------------------- ------------------- ---------------------------------------------
PRODID MUST METHOD 1 MUST be "CANCEL"
VERSION MUST be "2.0" VTODO 1
METHOD MUST be "CANCEL" ATTENDEE 0+ include all "Attendees" being removed from
VTODO MUST the todo. MUST include all "Attendees" if
UID MUST must echo original UID the entire todo is cancelled.
DTSTAMP MUST UID 1 MUST must echo original UID
ORGANIZER MUST DTSTAMP 1
SEQUENCE MUST ORGANIZER 1
SEQUENCE 1
Silverberg/Mansour/Dawson/Hopson 40 Expires September 1998 ATTACH 0+
RECURRENCE-ID MUST only if referring to one or more instances CATEGORIES 0 or 1 This property MAY contain a list of values
of a recurring calendar component. Otherwise CLASS 0 or 1
it MUST NOT be present COMMENT 0 or 1
COMMENT MAY
ATTENDEE MAY Silverberg/Mansour/Daws/Hopson 41 Expires November 1998
DTSTART MAY CONTACT 0+
CREATED MAY CREATED 0 or 1
DESCRIPTION MAY DESCRIPTION 0 or 1
ORGANIZER MAY DTSTART 0 or 1
PRIORITY MAY DUE 0 or 1 If present DURATION MUST NOT be present
CLASS MAY DURATION 0 or 1 If present DUE MUST NOT be present
CATEGORIES MAY EXDATE 0+
CONTACT MAY EXRULE 0+
CREATED MAY GEO 0 or 1
DTEND MAY LAST-MODIFIED 0 or 1
GEO MAY LOCATION 0 or 1
LAST-MODIFIED MAY PERCENT-COMPLETE 0 or 1
LOCATION MAY RDATE 0+
PERCENT-COMPLETE MAY RECURRENCE-ID 0 or 1 MUST only if referring to one or more
PRIORITY MAY instances of a recurring calendar
RDATE MAY component. Otherwise it MUST NOT be
RRULE MAY present.
RELATED-TO MAY RELATED-TO 0+
REQUEST-STATUS MAY RESOURCES 0 or 1 This property MAY contain a list of values
RESOURCE MAY RRULE 0+
STATUS MAY If present it must be set to "CANCELLED". PRIORITY 0 or 1
STATUS 0 or 1 If present it MUST be set to "CANCELLED".
MUST NOT be used if purpose is to remove MUST NOT be used if purpose is to remove
"ATTENDEES" rather than cancel the entire "ATTENDEES" rather than cancel the entire
VTODO. VTODO.
TRANSP MAY URL 0 or 1
URL MAY X-PROPERTY 0+
VTIMEZONE MUST be present if any date/time refers to a REQUEST-STATUS 0
timezone
VALARM MAY VTIMEZONE 0 or 1 MUST be present if any date/time refers to
VEVENT MAY a timezone
VFREEBUSY MAY X-COMPONENT 0+
X-TOKENS MAY
VALARM 0
VEVENT 0
VFREEBUSY 0
3.4.6 REFRESH 3.4.6 REFRESH
The "REFRESH" method in a "VTODO" calendar component is used by The "REFRESH" method in a "VTODO" calendar component is used by
"Attendees" of an existing "VTODO" calendar component to request an "Attendees" of an existing "VTODO" calendar component to request an
updated description from the "Organizer" of the "VTODO" calendar updated description from the "Organizer" of the "VTODO" calendar
component. The "Organizer" of the "VTODO" calendar component MAY use component. The "Organizer" of the "VTODO" calendar component MAY use
this method to request an updated status from the "Attendees". The this method to request an updated status from the "Attendees". The
"REFRESH" method MUST specify the "UID" property corresponding to the "REFRESH" method MUST specify the "UID" property corresponding to the
"VTODO" calendar component needing update. "VTODO" calendar component needing update.
A refresh of a recurrence instance of a "VTODO" calendar component may A refresh of a recurrence instance of a "VTODO" calendar component may
be requested by specifying the "RECURRENCE-ID" property corresponding to be requested by specifying the "RECURRENCE-ID" property corresponding to
the associated "VTODO" calendar component. The "Organizer" responds with the associated "VTODO" calendar component. The "Organizer" responds with
the latest description and rendition of the "VTODO" calendar component. the latest description and rendition of the "VTODO" calendar component.
In most cases this will be a REQUEST unless the "VTODO" has been
Silverberg/Mansour/Dawson/Hopson 41 Expires September 1998 Silverberg/Mansour/Daws/Hopson 42 Expires November 1998
cancelled, in which case the ORGANIZER MUST send a "CANCEL". This method
This method is intended to facilitate machine processing of requests for is intended to facilitate machine processing of requests for updates to
updates to a "VTODO" calendar component. a "VTODO" calendar component.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- --------------------------------------------- ------------------- ---------------------------------------------
PRODID MUST METHOD 1 MUST be "REFRESH"
VERSION MUST be "2.0" VTODO 1
METHOD MUST be "REFRESH" ATTENDEE 1
VTODO MUST DTSTAMP 1
ATTENDEE MUST UID 1 MUST echo original UID
DTSTAMP MUST
RECURRENCE-ID MUST only if referring to an instance of a RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
Recurring calendar component. Otherwise it Recurring calendar component. Otherwise it
MUST NOT be present MUST NOT be present
UID MUST echo original UID X-PROPERTY 0+
COMMENT MAY
REQUEST-STATUS MAY
DTSTART MAY
CREATED MAY
DESCRIPTION MAY
PRIORITY MAY
CLASS MAY
CATEGORIES MAY
CONTACT MAY
CREATED MAY
DTEND MAY
GEO MAY
LAST-MODIFIED MAY
PERCENT-COMPLETE MAY
ORGANIZER MAY
PRIORITY MAY
LOCATION MAY
RDATE MAY
RRULE MAY
RELATED-TO MAY
RESOURCE MAY
SEQUENCE MAY
STATUS MAY
TRANSP MAY
URL MAY
VTIMEZONE MUST be present if any date/time refers to a
timezone
VALARM MAY
VEVENT MAY
VFREEBUSY MAY
X-TOKENS MAY
Silverberg/Mansour/Dawson/Hopson 42 Expires September 1998 ATTACH 0
CATEGORIES 0
CLASS 0
COMMENT 0
CONTACT 0
CREATED 0
DESCRIPTION 0
DTSTART 0
DUE 0
DURATION 0
EXDATE 0
EXRULE 0
GEO 0
LAST-MODIFIED 0
LOCATION 0
ORGANIZER 0
PERCENT-COMPLETE 0
PRIORITY 0
RDATE 0
RELATED-TO 0
REQUEST-STATUS 0
RESOURCES 0
RRULE 0
SEQUENCE 0
STATUS 0
URL 0
X-COMPONENT 0+
VALARM 0
VEVENT 0
VFREEBUSY 0
VTIMEZONE 0
Silverberg/Mansour/Daws/Hopson 43 Expires November 1998
3.4.7 COUNTER 3.4.7 COUNTER
The "COUNTER" method in a "VTODO" calendar component is used by an The "COUNTER" method in a "VTODO" calendar component is used by an
"Attendee" of an existing "VTODO" calendar component to submit to the "Attendee" of an existing "VTODO" calendar component to submit to the
"Organizer" a counter proposal for the "VTODO" calendar component. The "Organizer" a counter proposal for the "VTODO" calendar component. The
"Attendee" sends the message to the "Organizer" of the "VTODO" calendar "Attendee" sends the message to the "Organizer" of the "VTODO" calendar
component. component.
The counter proposal is an iCalendar object consisting of a "VTODO" The counter proposal is an iCalendar object consisting of a "VTODO"
calendar component describing the complete description of the alternate calendar component describing the complete description of the alternate
"VTODO" calendar component. "VTODO" calendar component.
The "Organizer" rejects the counter proposal by sending the "Attendee" a The "Organizer" rejects the counter proposal by sending the "Attendee" a
"DECLINE-COUNTER" method. The "Organizer" accepts the counter proposal "DECLINECOUNTER" method. The "Organizer" accepts the counter proposal by
by sending all of the "Attendees" of the "VTODO" calendar component a sending all of the "Attendees" of the "VTODO" calendar component a
"REQUEST" method rescheduling the "VTODO" calendar component. In the "REQUEST" method rescheduling the "VTODO" calendar component. In the
latter case, the "Organizer" SHOULD reset the individual "RSVP" property latter case, the "Organizer" SHOULD reset the individual "RSVP" property
parameter values to TRUE on each "ATTENDEE" property; in order to force parameter values to TRUE on each "ATTENDEE" property; in order to force
a response by the "Attendees". a response by the "Attendees".
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "COUNTER"
VERSION MUST be "2.0" VTODO 1
METHOD MUST be "COUNTER" ATTENDEE 1+
VTODO MUST DTSTAMP 1
DTSTAMP MUST ORGANIZER 1
DTSTART MAY PRIORITY 1
ORGANIZER MUST SUMMARY 1 Can be null
RECURRENCE-ID MUST only if referring to an instance of a UID 1
ATTACH 0+
CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DTSTART 0 or 1
DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1
RDATE 0+
Silverberg/Mansour/Daws/Hopson 44 Expires November 1998
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise it recurring calendar component. Otherwise it
MUST NOT be present. MUST NOT be present.
SEQUENCE MUST be present if NOT 0, MAY be present if 0 RELATED-TO 0+
SUMMARY MUST be present; MAY be NULL REQUEST-STATUS 0+
UID MUST RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0 or 1
SEQUENCE 0 or 1 MUST echo the original SEQUENCE number.
MUST be present if non-zero. MAY be present
if zero.
STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
PROCESS/CANCELLED
URL 0 or 1
X-PROPERTY 0+
ATTENDEE MAY VALARM 0+
ATTACH MAY VTIMEZONE 0 or 1 MUST be present if any date/time refers to
CATEGORIES MAY a timezone
CLASS MAY X-COMPONENT 0+
COMMENT MAY
CONTACT MAY
CREATED MAY
DESCRIPTION MAY be present; MAY be NULL
DURATION MAY
DTEND MAY
EXDATE MAY
EXRULE MAY
GEO MAY
LAST-MODIFIED MAY
Silverberg/Mansour/Dawson/Hopson 43 Expires September 1998 VEVENT 0
LOCATION MAY VFREEBUSY 0
PERCENT-COMPLETE MAY
PRIORITY MAY
RELATED-TO MAY
RDATE MAY
RESOURCES MAY
RRULE MAY
STATUS MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS
TRANSP MAY
URL MAY
VEVENT MAY
VJOURNAL MAY
VTIMEZONE MUST be present if any date/time refers to a
timezone
VALARM MAY
VFREEBUSY MAY
X-TOKENS MAY
3.4.8 DECLINECOUNTER 3.4.8 DECLINECOUNTER
The "DECLINE-COUNTER" method in a "VTODO" calendar component is used by The "DECLINECOUNTER" method in a "VTODO" calendar component is used by
an "Organizer" of "VTODO" calendar component to reject a counter an "Organizer" of "VTODO" calendar component to reject a counter
proposal offered by one of the "Attendees". The "Organizer" sends the proposal offered by one of the "Attendees". The "Organizer" sends the
message to the "Attendee" that sent the "COUNTER" method to the message to the "Attendee" that sent the "COUNTER" method to the
"Organizer". "Organizer".
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- --------------------------------------------- ------------------- ---------------------------------------------
PRODID MUST METHOD 1 MUST be "DECLINECOUNTER"
VERSION MUST be "2.0"
METHOD MUST be "DECLINECOUNTER" VTODO 1
ATTENDEE 1+ MUST for all attendees
DTSTAMP 1
ORGANIZER 1
SEQUENCE 1 MUST echo the original SEQUENCE number
UID 1 MUST echo original UID
VTODO MUST ATTACH 0+
ATTENDEE MUST for all attendees CATEGORIES 0 or 1 This property may contain a list of values
UID MUST must echo original UID CLASS 0 or 1
DTSTAMP MUST COMMENT 0 or 1
SEQUENCE MUST CONTACT 0+
RECURRENCE-ID MUST only if referring to an instance of a CREATED 0 or 1
recurring calendar component. Otherwise it DESCRIPTION 0 or 1
MUST NOT be present. DTSTART 0 or 1
COMMENT MAY Silverberg/Mansour/Daws/Hopson 45 Expires November 1998
PERCENT-COMPLETE MAY DUE 0 or 1 If present DURATION MUST NOT be present
REQUEST-STATUS MAY DURATION 0 or 1 If present DUE MUST NOT be present
DTSTART MAY EXDATE 0+
CREATED MAY EXRULE 0+
DESCRIPTION MAY GEO 0 or 1
ORGANIZER MAY LAST-MODIFIED 0 or 1
PRIORITY MAY LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1
PRIORITY 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise
it MUST NOT be present.
RELATED-TO 0+
REQUEST-STATUS 0+
RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+
STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
PROCESS
URL 0 or 1
X-PROPERTY 0+
Silverberg/Mansour/Dawson/Hopson 44 Expires September 1998 VTIMEZONE 0+ MUST be present if any date/time refers to
CLASS MAY a timezone
CATEGORIES MAY X-COMPONENT 0+
CONTACT MAY
CREATED MAY
DTEND MAY
GEO MAY
LAST-MODIFIED MAY
LOCATION MAY
RDATE MAY
RRULE MAY
RELATED-TO MAY
RESOURCE MAY
STATUS MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS
TRANSP MAY
URL MAY
VTIMEZONE MUST be present if any date/time refers to a VALARM 0
timezone VEVENT 0
VALARM MAY VFREEBUSY 0
VEVENT MAY
VTODO MAY
VFREEBUSY MAY
X-TOKENS MAY
3.5 Methods For VJOURNAL Components 3.5 Methods For VJOURNAL Components
This section defines the property set for the methods that are This section defines the property set for the methods that are
applicable to the "VJOURNAL" calendar component. applicable to the "VJOURNAL" calendar component.
The following summarizes the methods that are defined for the "VJOURNAL" The following summarizes the methods that are defined for the "VJOURNAL"
calendar component. calendar component.
+================+==================================================+ +================+==================================================+
skipping to change at line 2325 skipping to change at line 2435
| PUBLISH | Post a journal entry. Used primarily as a method | | PUBLISH | Post a journal entry. Used primarily as a method |
| | of advertising the existence of a journal entry. | | | of advertising the existence of a journal entry. |
| | | | | |
| ADD | Add one or more instances to an existing journal | | ADD | Add one or more instances to an existing journal |
| | entry. | | | entry. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | journal entry. | | | journal entry. |
+================+==================================================+ +================+==================================================+
Silverberg/Mansour/Daws/Hopson 46 Expires November 1998
3.5.1 PUBLISH 3.5.1 PUBLISH
The "PUBLISH" method in a "VJOURNAL" calendar component has no The "PUBLISH" method in a "VJOURNAL" calendar component has no
associated response. It is simply a posting of an iCalendar object that associated response. It is simply a posting of an iCalendar object that
may be added to a calendar by a CUA. There is no response to the may be added to a calendar. It MUST have an "Organizer". It MUST NOT
"Organizer". The expected usage is for encapsulating an arbitrary have "Attendees". The expected usage is for encapsulating an arbitrary
journal entry as an iCalendar object. The "Organizer" MAY subsequently journal entry as an iCalendar object. The "Organizer" MAY subsequently
Silverberg/Mansour/Dawson/Hopson 45 Expires September 1998
update (with another "PUBLISH" method) or cancel (with a "CANCEL" update (with another "PUBLISH" method) or cancel (with a "CANCEL"
method) a previously published journal entry. method) a previously published journal entry.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "PUBLISH"
VERSION MUST be "2.0" VJOURNAL 1+
METHOD MUST be "PUBLISH" DESCRIPTION 1 Can be null.
VJOURNAL MUST DTSTAMP 1
DTSTAMP MUST DTSTART 1
DTSTART MUST ORGANIZER 1
ORGANIZER MUST UID 1
RECURRENCE-ID MUST only if referring to an instance of a
recurring calendar component. Otherwise it
MUST NOT be present.
SEQUENCE MUST be present if not 0, MAY be present if 0
SUMMARY MUST be present and MAY be NULL
UID MUST
ATTENDEE MAY ATTACH 0+
ATTACH MAY CATEGORIES 0 or 1 This property MAY contain a list of values
CATEGORIES MAY CLASS 0 or 1
CLASS MAY COMMENT 0 or 1
COMMENT MAY CONTACT 0+
CONTACT MAY CREATED 0 or 1
CREATED MAY EXDATE 0+
DESCRIPTION MAY be present; MAY be NULL. EXRULE 0+
DURATION MAY LAST-MODIFIED 0 or 1
DTEND MAY RDATE 0+
EXDATE MAY RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
EXRULE MAY recurring calendar component. Otherwise
GEO MAY it MUST NOT be present.
LAST-MODIFIED MAY RELATED-TO 0+
LOCATION MAY RRULE 0+
PRIORITY MAY SEQUENCE 0 or 1 MUST echo the original SEQUENCE number.
RELATED-TO MAY MUST be present if non-zero. MAY be
RDATE MAY present if zero.
RESOURCES MAY STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED
RRULE MAY SUMMARY 0 or 1 Can be null
STATUS MAY be one of DRAFT/FINAL/CANCELLED URL 0 or 1
TRANSP MAY X-PROPERTY 0+
URL MAY
VEVENT MAY ATTENDEE 0
VTODO MAY
VTIMEZONE MUST be present if any date/time refers to a
timezone
VALARM MAY
VFREEBUSY MAY
X-TOKENS MAY
Silverberg/Mansour/Dawson/Hopson 46 Expires September 1998 VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VEVENT 0
Silverberg/Mansour/Daws/Hopson 47 Expires November 1998
VFREEBUSY 0
VTODO 0
3.5.2 ADD 3.5.2 ADD
The "ADD" method in a "VJOURNAL" calendar component is used to add one The "ADD" method in a "VJOURNAL" calendar component is used to add one
or more instances to an existing "VJOURNAL" entry. There is no response or more instances to an existing "VJOURNAL" entry. There is no response
to the "Organizer". to the "Organizer".
If the "UID" property value in the "ADD" is not found on the recipient's If the "UID" property value in the "ADD" is not found on the recipient's
calendar, then the recipient MAY treat the "ADD" as a "PUBLISH". calendar, then the recipient MAY treat the "ADD" as a "PUBLISH".
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
PRODID MUST METHOD 1 MUST be "ADD"
VERSION MUST be "2.0" VJOURNAL 1
METHOD MUST be "ADD" DESCRIPTION 1 Can be null.
VJOURNAL MUST DTSTAMP 1
DTSTAMP MUST DTSTART 1
DTSTART MUST ORGANIZER 1
ORGANIZER MUST SEQUENCE 1 MUST be greater than 0
SEQUENCE MUST be greater than 0 UID 1 MUST match that of the original journal
SUMMARY MUST be present and MAY be NULL
UID MUST match that of the original journal
ATTACH MAY ATTACH 0+
CATEGORIES MAY CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS MAY CLASS 0 or 1
COMMENT MAY COMMENT 0 or 1
CONTACT MAY CONTACT 0+
CREATED MAY CREATED 0 or 1
DESCRIPTION MAY be present; may be null. EXDATE 0+
DURATION MAY EXRULE 0+
DTEND MAY LAST-MODIFIED 0 or 1
EXDATE MAY RDATE 0+
EXRULE MAY RELATED-TO 0+
GEO MAY RRULE 0+
LAST-MODIFIED MAY STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED
LOCATION MAY SUMMARY 0 or 1 Can be null
PRIORITY MAY URL 0 or 1
RELATED-TO MAY X-PROPERTY 0+
RDATE MAY
RESOURCES MAY
RRULE MAY
STATUS MAY be one of DRAFT/FINAL/CANCELLED
TRANSP MAY
URL MAY
ATTENDEE NOT ATTENDEE 0
RECURRENCE-ID NOT RECURRENCE-ID 0
VEVENT MAY VALARM 0+
VTODO MAY VTIMEZONE 0 or 1 MUST be present if any date/time refers to
VTIMEZONE MUST be present if any date/time refers to a a timezone
X-COMPONENT 0+
Silverberg/Mansour/Dawson/Hopson 47 Expires September 1998 VEVENT 0
timezone VFREEBUSY 0
VALARM MAY
VFREEBUSY MAY Silverberg/Mansour/Daws/Hopson 48 Expires November 1998
X-TOKENS MAY VTODO 0
3.5.3 CANCEL 3.5.3 CANCEL
The "CANCEL" method in a "VJOURNAL" calendar component is used to send a The "CANCEL" method in a "VJOURNAL" calendar component is used to send a
cancellation notice of an existing journal entry. The message is sent by cancellation notice of an existing journal entry. The message is sent by
the "Organizer" of a journal entry. For a recurring journal entry, the "Organizer" of a journal entry. For a recurring journal entry,
either the whole journal entry or instances of a journal entry may be either the whole journal entry or instances of a journal entry may be
cancelled. To cancel the complete range of a recurring journal entry, cancelled. To cancel the complete range of a recurring journal entry,
the "UID" property value for the journal entry MUST be specified and a the "UID" property value for the journal entry MUST be specified and a
"RECURRENCE-ID" property MUST NOT be specified in the "CANCEL" method. "RECURRENCE-ID" property MUST NOT be specified in the "CANCEL" method.
skipping to change at line 2477 skipping to change at line 2574
(a) the "RECURRENCE-ID" property for an instance in the sequence MUST be (a) the "RECURRENCE-ID" property for an instance in the sequence MUST be
specified with the "RANGE" property parameter value of THISANDPRIOR specified with the "RANGE" property parameter value of THISANDPRIOR
(or THISANDFUTURE) to indicate cancellation of the specified "VTODO" (or THISANDFUTURE) to indicate cancellation of the specified "VTODO"
calendar component and all instances before (or after); or calendar component and all instances before (or after); or
(b) individual recurrence instances may be cancelled by specifying (b) individual recurrence instances may be cancelled by specifying
multiple "RECURRENCE-ID" properties corresponding to the instances to multiple "RECURRENCE-ID" properties corresponding to the instances to
be cancelled. be cancelled.
When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be
incremented.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- --------------------------------------------- ------------------- ---------------------------------------------
PRODID MUST METHOD 1 MUST be "CANCEL"
VERSION MUST be "2.0" VJOURNAL 1+ All MUST have the same UID
METHOD MUST be "CANCEL" DTSTAMP 1
VJOURNAL MUST ORGANIZER 1
DTSTAMP MUST SEQUENCE 1
ORGANIZER MUST UID 1 MUST be the UID of the original REQUEST
RECURRENCE-ID MUST only if referring to an instance of a
recurring calendar component. Otherwise it
MUST NOT be present.
SEQUENCE MUST
UID MUST be the UID of the original REQUEST
COMMENT MAY ATTACH 0+
STATUS MAY be present, must be "CANCELLED" if present ATTENDEE 0+
ATTACH MAY CATEGORIES 0 or 1 This property MAY contain a list of values
ATTENDEE MAY CLASS 0 or 1
CATEGORIES MAY COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1
DTSTART 0 or 1
EXDATE 0+
Silverberg/Mansour/Dawson/Hopson 48 Expires September 1998 Silverberg/Mansour/Daws/Hopson 49 Expires November 1998
CLASS MAY EXRULE 0+
CONTACT MAY LAST-MODIFIED 0 or 1
CREATED MAY RDATE 0+
DESCRIPTION MAY RECURRENCE-ID 0 or 1 only if referring to an instance of a
DTSTART MAY recurring calendar component. Otherwise
DTEND MAY it MUST NOT be present.
EXDATE MAY RELATED-TO 0+
EXRULE MAY RRULE 0+
GEO MAY STATUS 0 or 1 MAY be present, must be "CANCELLED" if
LAST-MODIFIED MAY present
%-COMPLETE MAY SUMMARY 0 or 1
PRIORITY MAY URL 0 or 1
RELATED-TO MAY X-PROPERTY 0+
REQUEST-STATUS MAY
RESOURCES MAY
RDATE MAY
RRULE MAY
STATUS MAY
SUMMARY MAY
TRANSP MAY
URL MAY
VTODO MAY REQUEST-STATUS 0
VEVENT MAY
VFREEBUSY MAY VTIMEZONE 0+ MUST be present if any date/time refers to
VTIMEZONE MUST be present if any date/time refers to a a timezone
timezone X-COMPONENT 0+
VALARM MAY VALARM 0
X-TOKENS MAY VEVENT 0
VFREEBUSY 0
VTODO 0
3.6 Status Replies 3.6 Status Replies
The "REQUEST-STATUS" property may include the following values: The "REQUEST-STATUS" property may include the following values:
|==============+============================+=========================| |==============+============================+=========================|
| Short Return | Longer Return Status | Offending Data | | Short Return | Longer Return Status | Offending Data |
| Status Code | Description | | | Status Code | Description | |
|==============+============================+=========================| |==============+============================+=========================|
| 2.0 | Success. | None. | | 2.0 | Success. | None. |
skipping to change at line 2553 skipping to change at line 2647
| | values. | | | | values. | |
|==============+============================+=========================| |==============+============================+=========================|
| 2.2 | Success, invalid property | Property name MAY be | | 2.2 | Success, invalid property | Property name MAY be |
| | ignored. | specified. | | | ignored. | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.3 | Success, invalid property | Property parameter name | | 2.3 | Success, invalid property | Property parameter name |
| | parameter ignored. | and value MAY be | | | parameter ignored. | and value MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.4 | Success, unknown non- | Non-standard property | | 2.4 | Success, unknown non- | Non-standard property |
Silverberg/Mansour/Dawson/Hopson 49 Expires September 1998
| | standard property ignored. | name MAY be specified. | | | standard property ignored. | name MAY be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.5 | Success, unknown non | Property and non- | | 2.5 | Success, unknown non | Property and non- |
| | standard property value | standard value MAY be | | | standard property value | standard value MAY be |
| | ignored. | specified. | | | ignored. | specified. |
|==============+============================+=========================| |==============+============================+=========================|
Silverberg/Mansour/Daws/Hopson 50 Expires November 1998
| 2.6 | Success, invalid calendar | Calendar component | | 2.6 | Success, invalid calendar | Calendar component |
| | component ignored. | sentinel (e.g., "BEGIN: | | | component ignored. | sentinel (e.g., BEGIN: |
| | | ALARM") MAY be | | | | ALARM) MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.7 | Success, request forwarded | Original and forwarded | | 2.7 | Success, request forwarded | Original and forwarded |
| | to Calendar User. | caluser addresses MAY | | | to Calendar User. | caluser addresses MAY |
| | | be specified. | | | | be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.8 | Success, repeating event | RRULE or RDATE property | | 2.8 | Success, repeating event | RRULE or RDATE property |
| | ignored. Scheduled as a | name and value MAY be | | | ignored. Scheduled as a | name and value MAY be |
| | single event. | specified. | | | single component. | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.9 | Success, truncated end date| DTEND property value | | 2.9 | Success, truncated end date| DTEND property value |
| | time to date boundary. | MAY be specified. | | | time to date boundary. | MAY be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.10 | Success, repeating VTODO | RRULE or RDATE property | | 2.10 | Success, repeating VTODO | RRULE or RDATE property |
| | ignored. Scheduled as a | name and value MAY be | | | ignored. Scheduled as a | name and value MAY be |
| | single VTODO. | specified. | | | single VTODO. | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.11 | Success, RRULE or EXRULE | RRULE or EXRULE property| | 2.11 | Success, unbounded RRULE | RRULE property name and |
| | too complex. Scheduled as | name and value MAY be |
| | a single event. | specified. |
|==============+============================+=========================|
| 2.12 | Success, unbounded RRULE | RRULE property name and |
| | clipped at some finite | value MAY be specified. | | | clipped at some finite | value MAY be specified. |
| | number of instances | Number of instances MAY | | | number of instances | Number of instances MAY |
| | | also be specified. | | | | also be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.0 | Invalid property name. | Property name MAY be | | 3.0 | Invalid property name. | Property name MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.1 | Invalid property value. | Property name and value | | 3.1 | Invalid property value. | Property name and value |
| | | MAY be specified. | | | | MAY be specified. |
|==============+============================+=========================| |==============+============================+=========================|
skipping to change at line 2610 skipping to change at line 2699
|==============+============================+=========================| |==============+============================+=========================|
| 3.3 | Invalid property parameter | Property parameter name | | 3.3 | Invalid property parameter | Property parameter name |
| | value. | and value MAY be | | | value. | and value MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.4 | Invalid calendar component | Calendar component | | 3.4 | Invalid calendar component | Calendar component |
| | sequence. | sentinel MAY be | | | sequence. | sentinel MAY be |
| | | specified (e.g., BEGIN: | | | | specified (e.g., BEGIN: |
| | | VTIMEZONE). | | | | VTIMEZONE). |
|==============+============================+=========================| |==============+============================+=========================|
Silverberg/Mansour/Dawson/Hopson 50 Expires September 1998
| 3.5 | Invalid date or time. | Date/time value(s) MAY | | 3.5 | Invalid date or time. | Date/time value(s) MAY |
| | | be specified. | | | | be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.6 | Invalid rule. | Rule value MAY be | | 3.6 | Invalid rule. | Rule value MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.7 | Invalid Calendar User. | Attendee property value | | 3.7 | Invalid Calendar User. | Attendee property value |
| | |MAY be specified. | | | |MAY be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.8 | No authority. | PROFILE and Attendee | | 3.8 | No authority. | METHOD and Attendee |
Silverberg/Mansour/Daws/Hopson 51 Expires November 1998
| | | property values MAY be | | | | property values MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.9 | Unsupported version. | VERSION property name | | 3.9 | Unsupported version. | VERSION property name |
| | | and value MAY be | | | | and value MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.10 | Request entity too large. | None. | | 3.10 | Request entity too large. | None. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.11 | Required component or | Component or property | | 3.11 | Required component or | Component or property |
| | property missing. | name MAY be specified. | | | property missing. | name MAY be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.12 | Unknown component or | Component or property |
| | property found | name MAY be specified |
|==============+============================+=========================|
| 3.13 | Unsupported component or | Component or property |
| | property found | name MAY be specified |
|==============+============================+=========================|
| 3.14 | Unsupported capability | Method or action MAY |
| | | be specified |
|==============+============================+=========================|
| 4.0 | Event conflict. Date/time | DTSTART and DTEND | | 4.0 | Event conflict. Date/time | DTSTART and DTEND |
| | is busy. | property name and values| | | is busy. | property name and values|
| | | MAY be specified. | | | | MAY be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 5.0 | Request MAY supported. | Method property value | | 5.0 | Request MAY supported. | Method property value |
| | | MAY be specified. | | | | MAY be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 5.1 | Service unavailable. | ATTENDEE property value | | 5.1 | Service unavailable. | ATTENDEE property value |
| | | MAY be specified. | | | | MAY be specified. |
|==============+============================+=========================| |==============+============================+=========================|
skipping to change at line 2664 skipping to change at line 2761
3.7.1 Working With Recurrence Instances 3.7.1 Working With Recurrence Instances
iCalendar includes a recurrence grammar to represent recurring events. iCalendar includes a recurrence grammar to represent recurring events.
The benefit of such a grammar is the ability to represent a number of The benefit of such a grammar is the ability to represent a number of
events in a single object. However, while this simplifies creation of a events in a single object. However, while this simplifies creation of a
recurring event, meeting instances still need to be referenced. For recurring event, meeting instances still need to be referenced. For
instance, an "Attendee" may decline the third instance of a recurring instance, an "Attendee" may decline the third instance of a recurring
Friday event. Similarly, the "Organizer" may change the time or location Friday event. Similarly, the "Organizer" may change the time or location
to a single instance of the recurring event. to a single instance of the recurring event.
Silverberg/Mansour/Dawson/Hopson 51 Expires September 1998
Since implementations may elect to store recurring events as either a Since implementations may elect to store recurring events as either a
single event object or a collection of discreet, related event objects, single event object or a collection of discreet, related event objects,
Silverberg/Mansour/Daws/Hopson 52 Expires November 1998
the protocol is designed so that each recurring instance may be both the protocol is designed so that each recurring instance may be both
referenced and versioned. Hence, implementations that choose to maintain referenced and versioned. Hence, implementations that choose to maintain
per-instance properties (such as "ATTENDEE" property "attstat" per-instance properties (such as "ATTENDEE" property "partstat"
parameter) may do so. However, the protocol does not require per- parameter) may do so. However, the protocol does not require per-
instance recognition unless the instance itself must be renegotiated. instance recognition unless the instance itself must be renegotiated.
The scenarios for recurrence instance referencing are listed below. For The scenarios for recurrence instance referencing are listed below. For
purposes of simplification a change to an event refers to a "trigger purposes of simplification a change to an event refers to a "trigger
property." That is, a property that has a substantive effect on the property." That is, a property that has a substantive effect on the
meeting itself such as start time, location, due date (for "VTODO" meeting itself such as start time, location, due date (for "VTODO"
calendar component components) and possibly description. calendar component components) and possibly description.
"Organizer" initiated actions: "Organizer" initiated actions:
. "Organizer" deletes or changes a single instance of a recurring event . "Organizer" deletes or changes a single instance of a recurring
event
. "Organizer" makes changes that affect all future instances . "Organizer" makes changes that affect all future instances
. "Organizer" makes changes that affect all previous instances . "Organizer" makes changes that affect all previous instances
. "Organizer" deletes or modifies a previously changed instance . "Organizer" deletes or modifies a previously changed instance
"Attendee" initiated actions: "Attendee" initiated actions:
. "Attendee" changes status for a particular recurrence instance . "Attendee" changes status for a particular recurrence instance
. "Attendee" sends Event-Counter for a particular recurrence instance . "Attendee" sends Event-Counter for a particular recurrence instance
An instance of a recurring event is assigned a unique identification, An instance of a recurring event is assigned a unique identification,
skipping to change at line 2714 skipping to change at line 2812
3.7.2 Attendee Property Considerations 3.7.2 Attendee Property Considerations
The "ORGANIZER" property is required on published events, to-dos, and The "ORGANIZER" property is required on published events, to-dos, and
journal entries for two reasons. First, only the "Organizer" is allowed journal entries for two reasons. First, only the "Organizer" is allowed
to update and redistribute an event or to-do component. It follows that to update and redistribute an event or to-do component. It follows that
the "ORGANIZER" property MUST be present in the event, to-do, or journal the "ORGANIZER" property MUST be present in the event, to-do, or journal
entry component so that the CUA has a basis for authorizing an update. entry component so that the CUA has a basis for authorizing an update.
Second, it is prudent to provide a point of contact for anyone who Second, it is prudent to provide a point of contact for anyone who
receives a published component in case of problems. receives a published component in case of problems.
There are valid RFC 822 addresses that represent groups. Sending email There are valid [RFC-822] addresses that represent groups. Sending email
to such an address results in mail being sent to multiple recipients. to such an address results in mail being sent to multiple recipients.
Such an address may be used as the value of an "ATTENDEE" property. Such an address may be used as the value of an "ATTENDEE" property.
Silverberg/Mansour/Dawson/Hopson 52 Expires September 1998 Silverberg/Mansour/Daws/Hopson 53 Expires November 1998
Thus, it is possible that the recipient of a "REQUEST" does not appear Thus, it is possible that the recipient of a "REQUEST" does not appear
explicitly in the list. explicitly in the list.
It is recommended that the general approach to finding a "Calendar User" It is recommended that the general approach to finding a "Calendar User"
in an attendee list be as follows: in an attendee list be as follows:
1. Search for the "Calendar User" in the attendee list where 1. Search for the "Calendar User" in the attendee list where
"TYPE=INDIVIDUAL" "TYPE=INDIVIDUAL"
2. Failing (1) look for attendees where "TYPE=GROUP" or 2. Failing (1) look for attendees where "TYPE=GROUP" or 'TYPE=UNKNOWN".
'TYPE=UNKNOWN". The CUA then determines if the "Calendar User" The CUA then determines if the "Calendar User" is a member of one of
is a member of one of these groups. If so, the "REPLY" method these groups. If so, the "REPLY" method sent to the "Organizer" MUST
sent to the "Organizer" MUST contain a new "ATTENDEE" property contain a new "ATTENDEE" property in which:
in which the "TYPE" property parameter is set to INDIVIDUAL and . the "type" property parameter is set to INDIVIDUAL
the "group" property parameter is set to the name of the group. . the "member" property parameter is set to the name of the group
3. Failing (2) the CUA MAY ignore or accept the request as the 3. Failing (2) the CUA MAY ignore or accept the request as the "Calendar
"Calendar User" wishes. User" wishes.
3.7.3 X-Tokens 3.7.3 X-Tokens
To make iCalendar objects extensible, new property types MAY be inserted To make iCalendar objects extensible, new property types MAY be inserted
into components. These properties are called X-Tokens as they are into components. These properties are called X-Tokens as they are
prefixed with "X-". A client is not required to make sense of X-Tokens. prefixed with "X-". A client is not required to make sense of X-Tokens.
Clients are not required to save X-Tokens or use them in replies. Clients are not required to save X-Tokens or use them in replies.
4 Examples 4 Examples
skipping to change at line 2772 skipping to change at line 2869
| Action | "Organizer" | | Action | "Organizer" |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Publish an event | "A" sends or posts a PUBLISH | | Publish an event | "A" sends or posts a PUBLISH |
| | message | | | message |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| "B" reads a published event | | | "B" reads a published event | |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Publish an updated event | "A" sends or posts a PUBLISH | | Publish an updated event | "A" sends or posts a PUBLISH |
| | message | | | message |
Silverberg/Mansour/Dawson/Hopson 53 Expires September 1998 Silverberg/Mansour/Daws/Hopson 54 Expires November 1998
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| "B" reads the updated event | | | "B" reads the updated event | |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Cancel a published event | "A" sends or posts a CANCEL | | Cancel a published event | "A" sends or posts a CANCEL |
| | message | | | message |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| "B" reads the canceled event | | | "B" reads the canceled event | |
| publication | | | publication | |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
skipping to change at line 2818 skipping to change at line 2914
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:PUBLISH METHOD:PUBLISH
VERSION:2.0 VERSION:2.0
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
DTSTAMP:19970612T190000Z DTSTAMP:19970612T190000Z
DTSTART:19970701T210000Z DTSTART:19970701T210000Z
DTEND:19970701T230000Z DTEND:19970701T230000Z
SEQUENCE:2 SEQUENCE:1
UID:0981234-1234234-23@example.com UID:0981234-1234234-23@example.com
SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Dawson/Hopson 54 Expires September 1998 Silverberg/Mansour/Daws/Hopson 55 Expires November 1998
The "UID" property is used by the client to identify the event. The The "UID" property is used by the client to identify the event. The
"SEQUENCE" property indicates that this is the second change to the "SEQUENCE" property indicates that this is a change to the event. The
event. Events with sequence numbers 0 and 1 are superseded by this event with a matching UID and sequence number 0 is superseded by this
event. event.
The "SEQUENCE" property provides a reliable way to distinguish different The "SEQUENCE" property provides a reliable way to distinguish different
versions of the same event. Each time an event is published, its versions of the same event. Each time an event is published, its
sequence number is incremented. If a client receives an event with a sequence number is incremented. If a client receives an event with a
sequence number 5 and finds it has the same event with sequence number sequence number 5 and finds it has the same event with sequence number
2, the event SHOULD be updated. However, if the client received an event 2, the event SHOULD be updated. However, if the client received an event
with sequence number 2 and finds it already has sequence number 5 of the with sequence number 2 and finds it already has sequence number 5 of the
same event, the event MUST NOT be updated. same event, the event MUST NOT be updated.
skipping to change at line 2866 skipping to change at line 2961
4.1.4 A Rich Published Event 4.1.4 A Rich Published Event
This example describes the same event as in 4.1.1, but in much greater This example describes the same event as in 4.1.1, but in much greater
detail. detail.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:PUBLISH METHOD:PUBLISH
SCALE:GREGORIAN SCALE:GREGORIAN
SOURCE:http://www.midwaystadium.com/stadium-cal/1997-events.or4
VERSION:2.0 VERSION:2.0
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America-Chicago TZID:America-Chicago
TZURL:http://zones.stds_r_us.net/tz/America-Chicago TZURL:http://zones.stds_r_us.net/tz/America-Chicago
LAST-MODIFIED:19870101T000000Z
BEGIN:STANDARD BEGIN:STANDARD
DTSTART:19671029T020000 DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0500 TZOFFSETFROM:-0500
TZOFFSETTO:-0600 TZOFFSETTO:-0600
TZNAME:CST TZNAME:CST
Silverberg/Mansour/Dawson/Hopson 55 Expires September 1998
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
Silverberg/Mansour/Daws/Hopson 56 Expires November 1998
DTSTART:19870405T020000 DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZOFFSETFROM:-0600 TZOFFSETFROM:-0600
TZOFFSETTO:-0500 TZOFFSETTO:-0500
TZNAME:CDT TZNAME:CDT
END:DAYLIGHT END:DAYLIGHT
END:VTIMEZONE END:VTIMEZONE
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTACH:http://www.midwaystadium.com ATTACH:http://www.dukes.com/
CATEGORIES:SPORTS EVENT,ENTERTAINMENT CATEGORIES:SPORTS EVENT,ENTERTAINMENT
CLASS:PRIVATE CLASS:PRIVATE
CREATED:19970415T194319Z
DESCRIPTION:MIDWAY STADIUM\n DESCRIPTION:MIDWAY STADIUM\n
Big time game. MUST see.\n Big time game. MUST see.\n
Expected duration:2 hours\n Expected duration:2 hours\n
DTEND;TZID=America-Chicago:19970701T180000 DTEND;TZID=America-Chicago:19970701T180000
DTSTART;TZID=America-Chicago:19970702T160000 DTSTART;TZID=America-Chicago:19970702T160000
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
STATUS:CONFIRMED STATUS:CONFIRMED
LAST-MODIFIED:19970416T162421Z
LOCATION;VALUE=URL:http://www.midwaystadium.com/ LOCATION;VALUE=URL:http://www.midwaystadium.com/
PRIORITY:2 PRIORITY:2
RESOURCES:SCOREBOARD RESOURCES:SCOREBOARD
SEQUENCE:3 SEQUENCE:3
SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
UID:0981234-1234234-23@example.com UID:0981234-1234234-23@example.com
RELATED-TO:0981234-1234234-14@example.com RELATED-TO:0981234-1234234-14@example.com
BEGIN:VALARM BEGIN:VALARM
TRIGGER:PT2H TRIGGER:-PT2H
ALARM-TYPE:DISPLAY ACTION:DISPLAY
DESCRIPTION:It's almost game time DESCRIPTION:You should be leaving for the game now.
END:VALARM END:VALARM
BEGIN:VALARM BEGIN:VALARM
TRIGGER:PT30M TRIGGER:-PT30M
ALARM-TYPE:AUDIO ACTION:AUDIO
DESCRIPTION:You SHOULD leave now. Game starts in 30 minutes!
END:VALARM END:VALARM
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The "RELATED-TO" field contains the "UID" property of a related calendar The "RELATED-TO" field contains the "UID" property of a related calendar
event. The "SEQUENCE" property 3 indicates that this event supersedes event. The "SEQUENCE" property 3 indicates that this event supersedes
versions 0, 1, and 2. versions 0, 1, and 2.
4.1.5 Anniversaries or Events attached to entire days 4.1.5 Anniversaries or Events attached to entire days
This example demonstrates the use of the "value" parameter to tie a This example demonstrates the use of the "value" parameter to tie a
VEVENT to day rather than a specific time. "VEVENT" to day rather than a specific time.
Silverberg/Mansour/Dawson/Hopson 56 Expires September 1998
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:PUBLISH METHOD:PUBLISH
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com
Silverberg/Mansour/Daws/Hopson 57 Expires November 1998
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
UID:0981234-1234234-23@example.com UID:0981234-1234234-23@example.com
DTSTART;VALUE=DATE:19970714 DTSTART;VALUE=DATE:19970714
RRULE:FREQ=YEARLY;INTERVAL=1 RRULE:FREQ=YEARLY;INTERVAL=1
SUMMARY: Bastille Day SUMMARY: Bastille Day
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2 Group Event Examples 4.2 Group Event Examples
skipping to change at line 2970 skipping to change at line 3058
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Initiate a meeting | "A" sends a REQUEST | | | Initiate a meeting | "A" sends a REQUEST | |
| request | message to "B", "C",| | | request | message to "B", "C",| |
| | and "D" | | | | and "D" | |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Accept the meeting | | "B" sends a REPLY | | Accept the meeting | | "B" sends a REPLY |
| request | | message to "A" with its | | request | | message to "A" with its |
| | | ATTENDEE "attstat" para-| | | | ATTENDEE "partstat" para-|
| | | set to "accepted" | | | | set to "accepted" |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Decline the meeting| | "C" sends a REPLY | | Decline the meeting| | "C" sends a REPLY |
| request | | message to "A" with its | | request | | message to "A" with its |
| | | ATTENDEE "attstat" para-| | | | ATTENDEE "partstat" para-|
| | | set to "declined" | | | | set to "declined" |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Tentatively accept | | "D" sends a REPLY | | Tentatively accept | | "D" sends a REPLY |
| the meeting request| | message to "A" with its | | the meeting request| | message to "A" with its |
| | | ATTENDEE "attstat" para-| | | | ATTENDEE "partstat" para-|
| | | set to "tentative" | | | | set to "tentative" |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Confirm meeting | "A" sends a REQUEST | | | Confirm meeting | "A" sends a REQUEST | |
| status with | message to "B" and | | | status with | message to "B" and | |
| attendees | "C" with updated | | | attendees | "D" with updated | |
| | information. | | | | information. | |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
Silverberg/Mansour/Dawson/Hopson 57 Expires September 1998
4.2.1 A Group Event Request 4.2.1 A Group Event Request
A sample meeting request is sent from "A" to "B", "C", and "D". _E_ is A sample meeting request is sent from "A" to "B", "C", and "D". _E_ is
also sent a copy of the request but is not expected to attend and need also sent a copy of the request but is not expected to attend and need
not reply. "E" illustrates how CUAs might implement a "CC" type feature. not reply. "E" illustrates how CUAs might implement an "FYI" type
Note the use of the "role" parameter. The default value for the "role"
parameter is "req-participant" and it need not be enumerated. In this Silverberg/Mansour/Daws/Hopson 58 Expires November 1998
case we are using the value "non-participant" to indicate "E" is a non- feature. Note the use of the "role" parameter. The default value for the
attending CU. The parameter is not needed on other "Attendees" since "role" parameter is "req-participant" and it need not be enumerated. In
this case we are using the value "non-participant" to indicate "E" is a
non-attending CU. The parameter is not needed on other "Attendees" since
"participant" is the default value. "participant" is the default value.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com
ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T200000Z DTSTART:19970701T200000Z
DTEND:19970701T203000Z DTEND:19970701T2000000Z
SUMMARY:Phone Conference SUMMARY:Conference
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.2 Reply To A Group Event Request 4.2.2 Reply To A Group Event Request
Attendee "B" accepts the meeting. Attendee "B" accepts the meeting.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ATTENDEE;ATTSTAT=ACCEPTED:Mailto:B@example.com ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com
ORGANIZER:MAILTO:A@example.com ORGANIZER:MAILTO:A@example.com
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
DTSTAMP:19970612T190000Z DTSTAMP:19970612T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Dawson/Hopson 58 Expires September 1998
"B" could have declined the meeting or indicated tentative acceptance by "B" could have declined the meeting or indicated tentative acceptance by
setting the ATTENDEE "attstat" parameter to "declined" or "tentative", setting the "ATTENDEE" "partstat" parameter to "declined" or
respectively. Also, "REQUEST-STATUS" is not required on a successful "tentative", respectively. Also, "REQUEST-STATUS" is not required in
transactions. successful transactions.
Silverberg/Mansour/Daws/Hopson 59 Expires November 1998
4.2.3 Update An Event 4.2.3 Update An Event
The event is moved to a different time. The combination of the "UID" The event is moved to a different time. The combination of the "UID"
property (unchanged) and the "SEQUENCE" (bumped to 1) properties property (unchanged) and the "SEQUENCE" (bumped to 1) properties
indicate the update. indicate the update.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
ATTENDEE;RSVP=FALSE;TYPE=ROOM:Mailto:Conf@example.com ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
CUTYPE=ROOM:Mailto:Conf@example.com
ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
DTSTART:19970701T180000Z DTSTART:19970701T180000Z
DTEND:19970701T1200000Z DTEND:19970701T190000Z
SUMMARY:Phone Conference SUMMARY:Phone Conference
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:1 SEQUENCE:1
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.4 Countering an Event Proposal 4.2.4 Countering an Event Proposal
"A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal to "A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal to
"A" to change the time and location. "A" to change the time and location.
"A" sends the following "REQUEST": "A" sends the following "REQUEST":
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
Silverberg/Mansour/Dawson/Hopson 59 Expires September 1998
DTSTART:19970701T190000Z DTSTART:19970701T190000Z
DTEND:19970701T200000Z DTEND:19970701T200000Z
SUMMARY:Discuss the Merits of the election results SUMMARY:Discuss the Merits of the election results
LOCATION:The Big Conference Room LOCATION:Green Conference Room
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777a@example.com
SEQUENCE:0 SEQUENCE:0
Silverberg/Mansour/Daws/Hopson 60 Expires November 1998
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"B" sends "COUNTER" to "A", requesting changes to time and place. "B" "B" sends "COUNTER" to "A", requesting changes to time and place. "B"
uses the "COMMENT" property to communicate a rationale for the change: uses the "COMMENT" property to communicate a rationale for the change.
Note that the "SEQUENCE" property is NOT incremented on a "COUNTER".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:COUNTER METHOD:COUNTER
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
DTSTART:19970701T160000Z DTSTART:19970701T160000Z
DTEND:19970701T190000Z DTEND:19970701T190000Z
DTSTAMP:19970612T190000Z DTSTAMP:19970612T190000Z
SUMMARY:Discuss the Merits of the election results SUMMARY:Discuss the Merits of the election results
LOCATION:The Small Conference Room LOCATION:Green Conference Room
COMMENT:This time works much better and I think the big conference COMMENT:This time works much better and I think the big conference
room is too big room is too big
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777a@example.com
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"A" accepts the changes from "B". To accept a counter-proposal, the "A" accepts the changes from "B". To accept a counter-proposal, the
"Organizer" sends a new Event REQUEST with an incremented sequence "Organizer" sends a new event "REQUEST" with an incremented sequence
number. number.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
DTSTART:19970701T160000Z DTSTART:19970701T160000Z
DTEND:19970701T190000Z DTEND:19970701T190000Z
Silverberg/Mansour/Dawson/Hopson 60 Expires September 1998
SUMMARY:Discuss the Merits of the election results - changed to SUMMARY:Discuss the Merits of the election results - changed to
meet B's schedule meet B's schedule
LOCATION:The Small Conference Room LOCATION:Green Conference Room
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:1 SEQUENCE:1
Silverberg/Mansour/Daws/Hopson 61 Expires November 1998
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Instead, "A" rejects "B's" counter proposal Instead, "A" rejects "B's" counter proposal
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:DECLINECOUNTER METHOD:DECLINECOUNTER
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
COMMENT:Sorry, I cannot change this meeting time COMMENT:Sorry, I cannot change this meeting time
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:1 SEQUENCE:0
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR
4.2.5 Delegating an Event 4.2.5 Delegating an Event
When delegating an event request to another "Calendar User", the When delegating an event request to another "Calendar User", the
"Delegator" must both update the "Organizer" with a "REPLY" and send a "Delegator" must both update the "Organizer" with a "REPLY" and send a
request to the "Delegate". There is currently no protocol limitation to request to the "Delegate". There is currently no protocol limitation to
delegation depth. It is possible for the original delegate to delegate delegation depth. It is possible for the original delegate to delegate
the meeting to someone else, and so on. When a request is delegated from the meeting to someone else, and so on. When a request is delegated from
one CUA to another there are a number of responsibilities required of one CUA to another there are a number of responsibilities required of
the "Delegator". They MUST: the "Delegator". The "Delegator" MUST:
. Send an REPLY to the "Organizer" with their "ATTENDEE" property . Send a "REPLY" to the "Organizer" with the following updates:
"attstat" parameter set to "delegated" . The "Delegator's" "ATTENDEE" property "partstat" parameter set to
. Include the delegate as an additional "Attendee" with the "delegated- "delegated" and the "delegated-to" parameter is set to the address
from" property parameter set to the value of the delegator of the "Delegate"
. Include the original UID of the "REQUEST" method . Add an additional "ATTENDEE" property for the "Delegate" with the
"delegated-from" property parameter set to the "Delegator"
. Indicate whether they want to continue to receive updates when the
"Organizer" sends out updated versions of the event. Setting the
"rsvp" property parameter to "TRUE" will cause the updates to be
sent, setting it to "FALSE" causes no further updates to be sent.
Note that in either case, if the "Delegate" declines the invitation
the "Delegator" will be notified.
. The "Delegator" MUST also send a copy of the original "REQUEST" . The "Delegator" MUST also send a copy of the original "REQUEST"
method to the "Delegate". The delegator modifies the request as method to the "Delegate".
follows:
. The "ATTENDEE" property "attstat" parameter for the delegator (sender
in this case) is set to "delegated"
. "ATTENDEE" "delegated-to" parameter is set to the address of the
"Delegate"
. An "ATTENDEE" property is added for the "Delegate"
It is not required that the "Delegate" include the "Delegator" in their It is not required that the "Delegate" include the "Delegator" in their
"REPLY" method. However, it is strongly advised since this will inform "REPLY" method. However, it is strongly advised since this will inform
the "Delegator" whether the "Delegate" plans to attend the meeting. If the "Delegator" whether the "Delegate" plans to attend the meeting.
[Editors note: How so?] If the "Delegate" declines the meeting, the
Silverberg/Mansour/Dawson/Hopson 61 Expires September 1998 "Delegator" may elect to delegate the "REQUEST" to another CUA. The
process is the same.
the "Delegate" declines the meeting, the "Delegator" may elect to
delegate the "REQUEST" to another CUA. The process is the same.
Silverberg/Mansour/Daws/Hopson 62 Expires November 1998
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
| Initiate a meeting | "A" sends a REQUEST | | | Initiate a meeting | "A" sends a REQUEST | |
| request | message to "B" and | | | request | message to "B" and | |
| | "C" | | | | "C" | |
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
| Delegate: | | "C" sends a REPLY to "A" | | Delegate: | | "C" sends a REPLY to "A" |
| "C" delegates to | | with the ATTENDEE. | | "C" delegates to | | with the ATTENDEE. |
| "E" | | "attstat"parameter set to| | "E" | | "partstat" parameter set |
| | | "delegated" and with a | | | | to "delegated" and with a|
| | | new "ATTENDEE" property | | | | new "ATTENDEE" property |
| | | for "E". "E's" ATTENDEE | | | | for "E". "E's" ATTENDEE |
| | | "delegated-from" param | | | | "delegated-from" param |
| | | is set to "C". "C's" | | | | is set to "C". "C's" |
| | | ATTENDEE "delegated-to" | | | | ATTENDEE "delegated-to" |
| | | param is set to "E". | | | | param is set to "E". |
| | | "C" sends REQUEST message| | | | "C" sends REQUEST message|
| | | to "E" with the original | | | | to "E" with the original |
| | | meeting request | | | | meeting request |
| | | information. The | | | | information. The |
| | | "attstat" property | | | | "partstat" property |
| | | parameter for "C" is set | | | | parameter for "C" is set |
| | | to "delegated" and the | | | | to "delegated" and the |
| | | "delegated-to" | | | | "delegated-to" |
| | | parameter is set to | | | | parameter is set to |
| | | the address of "E". An | | | | the address of "E". An |
| | | "ATTENDEE" property is | | | | "ATTENDEE" property is |
| | | added for "E" and the | | | | added for "E" and the |
| | | "delegated-from" | | | | "delegated-from" |
| | | parameter is set to | | | | parameter is set to |
| | | the address of "C". | | | | the address of "C". |
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
| Confirm meeting | | "E" sends REPLY message | | Confirm meeting | | "E" sends REPLY message |
| attendance | | to "A" and optionally "C"| | attendance | | to "A" and optionally "C"|
| | | with its "attstat" | | | | with its "partstat" |
| | | property parameter set | | | | property parameter set |
| | | to "accepted" | | | | to "ACCEPTED" |
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
| Optional: | "A" sends REQUEST | | | Optional: | "A" sends REQUEST | |
| Redistribute | message to "B", "C" | | | Redistribute | message to "B", "C" | |
| meeting to | and "E". SEQUENCE | | | meeting to | and "E". | |
| attendees | number is now 1. | | | attendees | | |
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
"C" responds to the "Organizer". "C" responds to the "Organizer".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REPLY METHOD:REPLY
Silverberg/Mansour/Dawson/Hopson 62 Expires September 1998
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:MAILTO:A@Example.com ORGANIZER:MAILTO:A@Example.com
ATTENDEE;ATTSTAT=DELEGATED;DELEGATED-
TO=Mailto:E@example.com:Mailto:C@example.com Silverberg/Mansour/Daws/Hopson 63 Expires November 1998
UID:www.acme.com-873970198738777@example.com ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
TO="Mailto:E@example.com":Mailto:C@example.com
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Attendee "C" delegates presence at the meeting to "E". Attendee "C" delegates presence at the meeting to "E".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ATTSTAT=DELEGATED;DELEGATED- ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
TO=Mailto:E@example.com:Mailto:C@example.com TO="Mailto:E@example.com":Mailto:C@example.com
ATTENDEE;ROLE=DELEGATE;RSVP=TRUE; ATTENDEE;RSVP=TRUE;
DELEGATED-FROM=Mailto:C@example.com:Mailto:E@example.com DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
DTSTART:19970701T180000Z DTSTART:19970701T180000Z
DTEND:19970701T120000Z DTEND:19970701T200000Z
SUMMARY:Phone Conference SUMMARY:Phone Conference
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
STATUS:CONFIRMED STATUS:CONFIRMED
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.6 Delegate Accepts the Meeting 4.2.6 Delegate Accepts the Meeting
To accept a delegated meeting, the delegate, "E", sends the following To accept a delegated meeting, the delegate, "E", sends the following
message to "A" and "C" message to "A" and "C":
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:MAILTO:A@Example.com ORGANIZER:MAILTO:A@Example.com
ATTENDEE;ATTSTAT=CONFIRMED;DELEGATED- ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
FROM=Mailto:C@example.com:Mailto:E@example.com FROM="Mailto:C@example.com":Mailto:E@example.com
ATTENDEE;ATTSTAT=DELEGATED;DELEGATED- ATTENDEE;PARTSTAT=DELEGATED;
TO=Mailto:E@example.com:Mailto:C@example.com DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:1 SEQUENCE:0
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
Silverberg/Mansour/Dawson/Hopson 63 Expires September 1998
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Daws/Hopson 64 Expires November 1998
4.2.7 Delegate Declines the Meeting 4.2.7 Delegate Declines the Meeting
In this example the "Delegate" declines the meeting request and sets the In this example the "Delegate" declines the meeting request and sets the
"ATTENDEE" property "attstat" parameter to DECLINED. The "Organizer" "ATTENDEE" property "partstat" parameter to "DECLINED". The "Organizer"
SHOULD resend the "REQUEST" to "C" with the "attstat" parameter of the SHOULD resend the "REQUEST" to "C" with the "partstat" parameter of the
"Delegate" set to "declined". This lets the "Delegator" know that the "Delegate" set to "declined". This lets the "Delegator" know that the
"Delegate" has declined and provides an opportunity to the "Delegator" "Delegate" has declined and provides an opportunity to the "Delegator"
to either accept the request or delegate it to another CU. to either accept the request or delegate it to another CU.
Response from "E" to "A" and "C". Response from "E" to "A" and "C". Note the use of the "COMMENT" property
"E" uses to indicate why the delegation was declined.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:MAILTO:A@Example.com ORGANIZER:MAILTO:A@Example.com
ATTENDEE;ATTSTAT=DECLINED;DELEGATED- ATTENDEE;PARTSTAT=DELEGATED;
FROM=Mailto:C@example.com:Mailto:E@example.com DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com
UID:www.acme.com-873970198738777@example.com ATTENDEE;PARTSTAT=DECLINED;
ATTENDEE;ATTSTAT=DELEGATED;DELEGATED- DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
TO=Mailto:E@example.com:Mailto:C@example.com COMMENT:Sorry, I will be out of town at that time.
SEQUENCE:1 UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"A" resends the "REQUEST" method to "C". "A" may also wish to express "A" resends the "REQUEST" method to "C". "A" may also wish to express
the fact that the item was delegated in the "COMMENT" property. the fact that the item was delegated in the "COMMENT" property.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REPLY METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:MAILTO:A@Example.com ORGANIZER:MAILTO:A@Example.com
ATTENDEE;ATTSTAT=DECLINED;DELEGATED- ATTENDEE;PARTSTAT=DECLINED;
FROM=Mailto:C@example.com:Mailto:E@example.com DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:2 SEQUENCE:0
REQUEST-STATUS:2.0;Success SUMMARY:Phone Conference
DTSTART:19970701T180000Z
DTEND:19970701T200000Z
DTSTAMP:19970614T200000Z DTSTAMP:19970614T200000Z
COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR
INVITATION INVITATION
END:VEVENT END:VEVENT
Silverberg/Mansour/Dawson/Hopson 64 Expires September 1998
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Daws/Hopson 65 Expires November 1998
4.2.8 Forwarding an Event Request 4.2.8 Forwarding an Event Request
The protocol does not prevent an "Attendee" from "forwarding" an The protocol does not prevent an "Attendee" from "forwarding" an
"VEVENT" calendar component to other "Calendar Users". Forwarding "VEVENT" calendar component to other "Calendar Users". Forwarding
differs from delegation in that the forwarded "Calendar User" (often differs from delegation in that the forwarded "Calendar User" (often
referred to as a "Party Crasher") does not replace the forwarding referred to as a "Party Crasher") does not replace the forwarding
"Calendar User". Implementations are not required to add the "Party "Calendar User". Implementations are not required to add the "Party
Crasher" to the "Attendee" list and hence there is no guarantee that a Crasher" to the "Attendee" list and hence there is no guarantee that a
"Party Crasher" will receive additional updates to the Event. The "Party Crasher" will receive additional updates to the Event. The
forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the
skipping to change at line 3405 skipping to change at line 3492
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Action | "Organizer" | "Attendee" | | Action | "Organizer" | "Attendee" |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Initiate a meeting | "A" sends a REQUEST | | | Initiate a meeting | "A" sends a REQUEST | |
| request | message to "B", "C",| | | request | message to "B", "C",| |
| | and "D" | | | | and "D" | |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Decline the meeting| | "B" sends a "REPLY" | | Decline the meeting| | "B" sends a "REPLY" |
| request | | message to "A" with its | | request | | message to "A" with its |
| | | "attstat" para- | | | | "partstat" para- |
| | | set to "declined". | | | | set to "declined". |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Cancel the meeting | "A" sends a CANCEL | | | Cancel the meeting | "A" sends a CANCEL | |
| | message to "B", "C" | | | | message to "B", "C" | |
| | and "D" | | | | and "D" | |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
The example shows how "A" cancels the event. The example shows how "A" cancels the event.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:CANCEL METHOD:CANCEL
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
Silverberg/Mansour/Dawson/Hopson 65 Expires September 1998
ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com
Silverberg/Mansour/Daws/Hopson 66 Expires November 1998
ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
COMMENT:Mr. B cannot attend. It's raining. Lets cancel. COMMENT:Mr. B cannot attend. It's raining. Lets cancel.
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:1
STATUS:CANCELLED STATUS:CANCELLED
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.10 Removing Attendees 4.2.10 Removing Attendees
"A" wants to remove "B" from a meeting. This is done by sending a "A" wants to remove "B" from a meeting. This is done by sending a
"CANCEL" to "B" and removing "B" from the attendee list in the master "CANCEL" to "B" and removing "B" from the attendee list in the master
copy of the event. copy of the event.
skipping to change at line 3466 skipping to change at line 3552
the "STATUS" property is omitted. This is used when the meeting itself the "STATUS" property is omitted. This is used when the meeting itself
is cancelled and not when the intent is to remove an "Attendee" from the is cancelled and not when the intent is to remove an "Attendee" from the
Event. Event.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:CANCEL METHOD:CANCEL
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE:mailto:B@example.com
COMMENT:You're off the hook for this meeting COMMENT:You're off the hook for this meeting
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
DTSTAMP:19970613T193000Z DTSTAMP:19970613T193000Z
SEQUENCE:1
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The updated master copy of the event is shown below. The "Organizer" MAY The updated master copy of the event is shown below. The "Organizer" MAY
resend the updated event to the remaining "Attendees". Note that "B" has resend the updated event to the remaining "Attendees". Note that "B" has
been removed. been removed.
Silverberg/Mansour/Daws/Hopson 67 Expires November 1998
BEGIN:VCALENDAR BEGIN:VCALENDAR
Silverberg/Mansour/Dawson/Hopson 66 Expires September 1998
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
ATTENDEE;TYPE=ROOM:CR_Big@example.com ATTENDEE;TYPE=ROOM:CR_Big@example.com
ATTENDEE;ROLE=NON-PARTICIPANT; ATTENDEE;ROLE=NON-PARTICIPANT;
RSVP=FALSE:Mailto:E@example.com RSVP=FALSE:Mailto:E@example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T200000Z DTSTART:19970701T200000Z
DTEND:19970701T203000Z DTEND:19970701T203000Z
SUMMARY:Phone Conference SUMMARY:Phone Conference
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:2
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.11 Replacing the Organizer 4.2.11 Replacing the Organizer
The scenario for this example begins with "A" as the "Organizer" for a The scenario for this example begins with "A" as the "Organizer" for a
recurring meeting with "B", "C", and "D". "A" receives a new job offer recurring meeting with "B", "C", and "D". "A" receives a new job offer
in another country and leaves without changing the "Organizer" to this in another country and drops out of touch. "A" left no forwarding
meeting. "A" left no forwarding address or way to be reached. Using address or way to be reached. Using out-of-band communication, the
out-of-band communication, the other "Attendees" eventually learn what other "Attendees" eventually learn what has happened and reach an
has happened and reach an agreement that "B" should become the new agreement that "B" should become the new "Organizer" for the meeting. To
"Organizer" for the meeting. To do this, "B" sends out a new version of do this, "B" sends out a new version of the event and the other
the event and the other "Attendees" agree to accept "B" as the new "Attendees" agree to accept "B" as the new "Organizer". "B" also removes
"Organizer". "B" also removes "A" from the event "A" from the event.
When the "Organizer" is replaced, the "SEQUENCE" property value MUST be
incremented.
This is the message "B" sends to "C" and "D" This is the message "B" sends to "C" and "D"
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:B@example.com ORGANIZER:Mailto:B@example.com
ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T200000Z DTSTART:19970701T200000Z
DTEND:19970701T203000Z DTEND:19970701T203000Z
RRULE:FREQ=WEEKLY RRULE:FREQ=WEEKLY
SUMMARY:Phone Conference SUMMARY:Phone Conference
UID:123456@example.com UID:123456@example.com
Silverberg/Mansour/Daws/Hopson 68 Expires November 1998
SEQUENCE:1 SEQUENCE:1
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Dawson/Hopson 67 Expires September 1998
4.3 Busy Time Examples 4.3 Busy Time Examples
Busy time objects can be used in several ways. First, a CU may Request Busy time objects can be used in several ways. First, a CU may request
busy time from another CU for a specific range of time. That request can busy time from another CU for a specific range of time. That request can
be answered with a busy time Reply. Additionally, a CU may simply be answered with a busy time Reply. Additionally, a CU may simply
publish busy their busy time for a given interval and point other CUs to publish busy their busy time for a given interval and point other CUs to
the published location. The following examples outline both scenarios. the published location. The following examples outline both scenarios.
Individual "A" publishes Busy time for one week. Individual "A" publishes busy time for one week.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//ENVERSION:2.0 PRODID:-//ACME/DesktopCalendar//EN
VERSION:2.0
METHOD:PUBLISH METHOD:PUBLISH
BEGIN:VFREEBUSY BEGIN:VFREEBUSY
DTSTAMP:19980101T124100Z DTSTAMP:19980101T124100Z
ATTENDEE:MAILTO:A@Example.com ORGANIZER:MAILTO:A@Example.com
DTSTART:19980101T124200Z DTSTART:19980101T124200Z
DTEND:19980107T124200Z DTEND:19980107T124200Z
FREEBUSY:19980101T180000Z/19980101T190000Z FREEBUSY:19980101T180000Z/19980101T190000Z
FREEBUSY:19980103T020000Z/19980103T050000Z FREEBUSY:19980103T020000Z/19980103T050000Z
FREEBUSY:19980107T020000Z/19980107T050000Z FREEBUSY:19980107T020000Z/19980107T050000Z
FREEBUSY:19980113T000000Z/19980113T010000Z FREEBUSY:19980113T000000Z/19980113T010000Z
FREEBUSY:19980115T190000Z/19980115T200000Z FREEBUSY:19980115T190000Z/19980115T200000Z
FREEBUSY:19980115T220000Z/19980115T230000Z FREEBUSY:19980115T220000Z/19980115T230000Z
FREEBUSY:19980116T013000Z/19980116T043000Z FREEBUSY:19980116T013000Z/19980116T043000Z
END:VFREEBUSY END:VFREEBUSY
skipping to change at line 3582 skipping to change at line 3672
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Initiate a busy | "A" sends "REQUEST" | | | Initiate a busy | "A" sends "REQUEST" | |
| time request | message to "B" and | | | time request | message to "B" and | |
| | and "C" | | | | and "C" | |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Reply to the "BUSY"| | "B" sends a "REPLY" | | Reply to the "BUSY"| | "B" sends a "REPLY" |
| request with "BUSY"| | message to "A" with | | request with "BUSY"| | message to "A" with |
| time data | | busy time data | | time data | | busy time data |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
Silverberg/Mansour/Daws/Hopson 69 Expires November 1998
4.3.1 Request Busy Time 4.3.1 Request Busy Time
"A" sends a "BUSY-REQUEST" to "B" and "C" for busy time "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time
Silverberg/Mansour/Dawson/Hopson 68 Expires September 1998
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VFREEBUSY BEGIN:VFREEBUSY
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR:Mailto:A@example.com ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:B@example.com
ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:C@example.com
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
DTSTART:19970701T080000Z DTSTART:19970701T080000Z
DTEND:19970701T200000 DTEND:19970701T200000
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
END:VFREEBUSY END:VFREEBUSY
END:VCALENDAR END:VCALENDAR
4.3.2 Reply To A Busy Time Request 4.3.2 Reply To A Busy Time Request
"B" sends a "REPLY" method type of a "VFREEBUSY" calendar component to "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component to
"A" "A"
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VFREEBUSY BEGIN:VFREEBUSY
ORGANIZER:MAILTO:A@example.com ORGANIZER:MAILTO:A@example.com
ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:B@example.com
DTSTART:19970701T080000Z DTSTART:19970701T080000Z
DTEND:19970701T200000Z DTEND:19970701T200000Z
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30H FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M
DTSTAMP:19970613T190030Z DTSTAMP:19970613T190030Z
END:VFREEBUSY END:VFREEBUSY
END:VCALENDAR END:VCALENDAR
"B" is busy from 09:00 to 10:00 and from 14:00 to 14:30. "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30.
4.4 Recurring Event and Time Zone Examples 4.4 Recurring Event and Time Zone Examples
4.4.1 A Recurring Event Spanning Time Zones 4.4.1 A Recurring Event Spanning Time Zones
This event describes a weekly phone conference. The "Attendees" are each This event describes a weekly phone conference. The "Attendees" are each
in a different time zone. in a different time zone.
Silverberg/Mansour/Daws/Hopson 70 Expires November 1998
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
Silverberg/Mansour/Dawson/Hopson 69 Expires September 1998
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America-SanJose TZID:America-SanJose
TZURL:http://zones.stds_r_us.net/tz/America-SanJose TZURL:http://zones.stds_r_us.net/tz/America-SanJose
LAST-MODIFIED:19870101T000000Z
BEGIN:STANDARD BEGIN:STANDARD
DTSTART:19671029T020000 DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0700 TZOFFSETFROM:-0700
TZOFFSETTO:-0800 TZOFFSETTO:-0800
TZNAME:PST TZNAME:PST
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19870405T020000 DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
skipping to change at line 3661 skipping to change at line 3745
TZNAME:PST TZNAME:PST
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19870405T020000 DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZOFFSETFROM:-0800 TZOFFSETFROM:-0800
TZOFFSETTO:-0700 TZOFFSETTO:-0700
TZNAME:PDT TZNAME:PDT
END:DAYLIGHT END:DAYLIGHT
END:VTIMEZONE END:VTIMEZONE
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A@example.COM ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A@example.COM
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp
DTSTAMP:19970613T190030Z DTSTAMP:19970613T190030Z
DTSTART;TZID=America-SanJose:19970701T140000 DTSTART;TZID=America-SanJose:19970701T140000
DTEND;TZID=America-SanJose:19970701T150000 DTEND;TZID=America-SanJose:19970701T150000
RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU
RDATE;TZID=America-SanJose:19970910T140000 RDATE;TZID=America-SanJose:19970910T140000
EXDATE;TZID=America-SanJose:19970909T140000 EXDATE;TZID=America-SanJose:19970909T140000
EXDATE;TZID=America-SanJose:19971028T140000 EXDATE;TZID=America-SanJose:19971028T140000
SUMMARY:Weekly Phone Conference SUMMARY:Weekly Phone Conference
UID:www.acme.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The first two components of this iCalendar object are the time zone The first two components of this iCalendar object are the time zone
components. The "DTSTART" date coincides with the first instance of the components. The "DTSTART" date coincides with the first instance of the
RRULE property. RRULE property.
The recurring meeting is defined in a particular time zone, presumably The recurring meeting is defined in a particular time zone, presumably
that of the originator. The client for each "Attendee" has the that of the originator. The client for each "Attendee" has the
responsibility of determining the recurrence time in the "Attendee's" responsibility of determining the recurrence time in the "Attendee's"
time zone. time zone.
skipping to change at line 3693 skipping to change at line 3775
components. The "DTSTART" date coincides with the first instance of the components. The "DTSTART" date coincides with the first instance of the
RRULE property. RRULE property.
The recurring meeting is defined in a particular time zone, presumably The recurring meeting is defined in a particular time zone, presumably
that of the originator. The client for each "Attendee" has the that of the originator. The client for each "Attendee" has the
responsibility of determining the recurrence time in the "Attendee's" responsibility of determining the recurrence time in the "Attendee's"
time zone. time zone.
The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT. The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT.
"Attendee" B@example.fr is in France where the local time on this date "Attendee" B@example.fr is in France where the local time on this date
is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in Japan
Silverberg/Mansour/Dawson/Hopson 70 Expires September 1998 Silverberg/Mansour/Daws/Hopson 71 Expires November 1998
where local time is 8 hours ahead of UTC or Wednesday, July 2 at 06:00.
is 7 hours later than PDT or 21:00. "Attendee" C@example.jp is in Japan The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property
where local time is 9 hours ahead of than UTC or Wednesday, July 2 at results in 20 instances. The last instance falls on Tuesday, November
07:00. The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE" 11, 1997 2:00pm PDT. The "RDATE" property adds another instance: WED,
property results in 20 instances. The last instance falls on Tuesday, 10-SEP-1997 2:00 PM PST.
November 11, 1997 2:00pm PST. The "RDATE" property adds another
instance: WED, 10-SEP-1997 2:00 PM PST.
There are two exceptions to this recurring appointment. The first one There are two exceptions to this recurring appointment. The first one
is: is:
TUE, 09-SEP-1997 21:00 GMT TUE, 09-SEP-1997 23:00 GMT
TUE, 09-SEP-1997 14:00 PDT TUE, 09-SEP-1997 14:00 PDT
WED, 10-SEP-1997 07:00 JDT WED, 10-SEP-1997 06:00 JST
and the second is: and the second is:
TUE, 28-OCT-1997 22:00 GMT TUE, 28-OCT-1997 23:00 GMT
TUE, 28-OCT-1997 14:00 PST TUE, 28-OCT-1997 14:00 PST
WED, 29-OCT-1997 07:00 JST WED, 29-OCT-1997 06:00 JST
4.4.2 Modify A Recurring Instance 4.4.2 Modify A Recurring Instance
In this example the "Organizer" issues a recurring meeting. Later the In this example the "Organizer" issues a recurring meeting. Later the
"Organizer" changes an instance of the event by changing the "DTSTART" "Organizer" changes an instance of the event by changing the "DTSTART"
property. Note the use of "RECURRENCE-ID" property and "SEQUENCE" property. Note the use of "RECURRENCE-ID" property and "SEQUENCE"
property in the second request. property in the second request.
Original Request: Original Request:
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
CREATED:19970526T083000Z
UID:guid-1@host1.com UID:guid-1@host1.com
SEQUENCE:0 SEQUENCE:0
RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:B@example.com
ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:C@example.com
ATTENDEE:Mailto:D@example.com ATTENDEE:Mailto:D@example.com
DESCRIPTION:IETF-C&S Conference Call DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970601T210000Z DTSTART:19970601T210000Z
DTEND:19970601T220000Z DTEND:19970601T220000Z
LOCATION:Conference Call LOCATION:Conference Call
DTSTAMP:19970526T083000Z DTSTAMP:19970526T083000Z
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Dawson/Hopson 71 Expires September 1998 Silverberg/Mansour/Daws/Hopson 72 Expires November 1998
The event request below is to change the time of a specific instance. The event request below is to change the time of a specific instance.
This changes the July 1st instance to July 3rd. This changes the July 1st instance to July 3rd.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
CREATED:19970526T083000Z
UID:guid-1@host1com UID:guid-1@host1com
RECURRENCE-ID:19970701T210000Z RECURRENCE-ID:19970701T210000Z
SEQUENCE:1 SEQUENCE:1
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:B@example.com
ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:C@example.com
ATTENDEE:Mailto:D@example.com ATTENDEE:Mailto:D@example.com
DESCRIPTION:IETF-C&S Conference Call DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970703T210000Z DTSTART:19970703T210000Z
DTEND:19970703T220000Z DTEND:19970703T220000Z
LOCATION:Conference Call LOCATION:Conference Call
DTSTAMP:19970626T093000Z DTSTAMP:19970626T093000Z
skipping to change at line 3792 skipping to change at line 3870
In this example the "Organizer" of a recurring event deletes the August In this example the "Organizer" of a recurring event deletes the August
1st instance. 1st instance.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:CANCEL METHOD:CANCEL
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@host1.com UID:guid-1@host1.com
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE:Mailto:B@example.com
ATTENDEE:Mailto:C@example.com
ATTENDEE:Mailto:D@example.com
RECURRENCE-ID:19970801T210000Z RECURRENCE-ID:19970801T210000Z
SEQUENCE:2 SEQUENCE:2
STATUS:CANCELLED STATUS:CANCELLED
DTSTAMP:19970721T093000Z DTSTAMP:19970721T093000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Dawson/Hopson 72 Expires September 1998 Silverberg/Mansour/Daws/Hopson 73 Expires November 1998
4.4.4 Cancel Recurring Event 4.4.4 Cancel Recurring Event
In this example the "Organizer" wishes to cancel the entire recurring In this example the "Organizer" wishes to cancel the entire recurring
event and any exceptions. event and any exceptions.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:CANCEL METHOD:CANCEL
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@host1.com UID:guid-1@host1.com
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE:Mailto:B@example.com
ATTENDEE:Mailto:C@example.com
ATTENDEE:Mailto:D@example.com
DTSTAMP:19970721T103000Z DTSTAMP:19970721T103000Z
SEQUENCE:2 STATUS:CANCELLED
SEQUENCE:3
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.4.5 Change All Future Instances 4.4.5 Change All Future Instances
This example changes the meeting location from a conference call to This example changes the meeting location from a conference call to
Seattle starting September 1 and extends to all future instances. Seattle starting September 1 and extends to all future instances.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
CREATED:19970526T083000Z
UID:guid-1@host1.com UID:guid-1@host1.com
RECURRENCE-ID;THISANDFUTURE:19970901T210000Z RECURRENCE-ID;THISANDFUTURE:19970901T210000Z
SEQUENCE:3 SEQUENCE:3
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;RSVP=TRUE:Mailto:B@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com
ATTENDEE;RSVP=TRUE:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com
ATTENDEE;RSVP=TRUE:Mailto:D@example.com ATTENDEE;RSVP=TRUE:Mailto:D@example.com
DESCRIPTION:IETF-C&S Discussion DESCRIPTION:IETF-C&S Discussion
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970901T210000Z DTSTART:19970901T210000Z
DTEND:19970901T220000Z DTEND:19970901T220000Z
LOCATION:Building 32, Microsoft, Seattle, WA LOCATION:Building 32, Microsoft, Seattle, WA
DTSTAMP:19970526T083000Z DTSTAMP:19970526T083000Z
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR