draft-ietf-calsify-2446bis-10.txt   rfc5546.txt 
Network Working Group C. Daboo, Ed. Network Working Group C. Daboo, Ed.
Internet-Draft Apple Inc. Request for Comments: 5546 Apple Inc.
Obsoletes: 2446 (if approved) October 4, 2009 Obsoletes: 2446 December 2009
Updates: 5545 (if approved) Updates: 5545
Intended status: Standards Track Category: Standards Track
Expires: April 7, 2010
iCalendar Transport-Independent Interoperability Protocol (iTIP) iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-10
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies a protocol that uses the iCalendar object
and may be updated, replaced, or obsoleted by other documents at any specification to provide scheduling interoperability between
time. It is inappropriate to use Internet-Drafts as reference different calendaring systems. This is done without reference to a
material or to cite them other than as "work in progress." specific transport protocol so as to allow multiple methods of
communication between systems. Subsequent documents will define
profiles of this protocol that use specific, interoperable methods of
communication between systems.
The list of current Internet-Drafts can be accessed at The iCalendar Transport-Independent Interoperability Protocol (iTIP)
http://www.ietf.org/ietf/1id-abstracts.txt. complements the iCalendar object specification by adding semantics
for group scheduling methods commonly available in current
calendaring systems. These scheduling methods permit two or more
calendaring systems to perform transactions such as publishing,
scheduling, rescheduling, responding to scheduling requests,
negotiating changes, or canceling.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 7, 2010. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document specifies a protocol using the iCalendar object described in the BSD License.
specification to provide scheduling interoperability between
different calendaring systems. This is done without reference to a
specific transport protocol so as to allow multiple methods of
communication between systems. Subsequent documents will define
profiles of this protocol using specific interoperable methods of
communications between systems.
iTIP complements the iCalendar object specification by adding This document may contain material from IETF Documents or IETF
semantics for group scheduling methods commonly available in current Contributions published or made publicly available before November
calendaring systems. These scheduling methods permit two or more 10, 2008. The person(s) controlling the copyright in some of this
calendaring systems to perform transactions such as publish, material may not have granted the IETF Trust the right to allow
schedule, reschedule, respond to scheduling requests, negotiation of modifications of such material outside the IETF Standards Process.
changes or cancel. Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 6 1. Introduction and Overview .......................................5
1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 1.1. Formatting Conventions .....................................5
1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 7 1.2. Related Documents ..........................................6
1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Roles ......................................................6
1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Methods ....................................................7
2. Interoperability Models . . . . . . . . . . . . . . . . . . . 9 2. Interoperability Models .........................................9
2.1. Application Protocol . . . . . . . . . . . . . . . . . . 10 2.1. Application Protocol ......................................10
2.1.1. Scheduling State . . . . . . . . . . . . . . . . . . 10 2.1.1. Scheduling State ...................................10
2.1.2. Delegation . . . . . . . . . . . . . . . . . . . . . 11 2.1.2. Delegation .........................................10
2.1.3. Acting on Behalf of other Calendar Users . . . . . . 11 2.1.3. Acting on Behalf of Other Calendar Users ...........11
2.1.4. Component Revisions . . . . . . . . . . . . . . . . . 11 2.1.4. Component Revisions ................................11
2.1.5. Message Sequencing . . . . . . . . . . . . . . . . . 13 2.1.5. Message Sequencing .................................12
3. Application Protocol Elements . . . . . . . . . . . . . . . . 14 3. Application Protocol Elements ..................................13
3.1. Common Component Restriction Tables . . . . . . . . . . . 15 3.1. Common Component Restriction Tables .......................15
3.1.1. VCALENDAR . . . . . . . . . . . . . . . . . . . . . . 15 3.1.1. VCALENDAR ..........................................15
3.1.2. VTIMEZONE . . . . . . . . . . . . . . . . . . . . . . 15 3.1.2. VTIMEZONE ..........................................15
3.1.3. VALARM . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.3. VALARM .............................................17
3.2. Methods for VEVENT Calendar Components . . . . . . . . . 17 3.2. Methods for VEVENT Calendar Components ....................17
3.2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.1. PUBLISH ............................................18
3.2.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.2. REQUEST ............................................20
3.2.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.3. REPLY ..............................................25
3.2.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.4. ADD ................................................27
3.2.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.5. CANCEL .............................................29
3.2.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.6. REFRESH ............................................31
3.2.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.7. COUNTER ............................................33
3.2.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 34 3.2.8. DECLINECOUNTER .....................................35
3.3. Methods For VFREEBUSY Components . . . . . . . . . . . . 36 3.3. Methods for VFREEBUSY Components ..........................37
3.3.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.1. PUBLISH ............................................37
3.3.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.2. REQUEST ............................................40
3.3.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3.3. REPLY ..............................................42
3.4. Methods For VTODO Components . . . . . . . . . . . . . . 41
3.4.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 55
3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 58
3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 60
3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 65
3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 67
3.7. Implementation Considerations . . . . . . . . . . . . . . 74
3.7.1. Working With Recurrence Instances . . . . . . . . . . 74
3.7.2. Attendee Property Considerations . . . . . . . . . . 75
3.7.3. Extension Tokens . . . . . . . . . . . . . . . . . . 75
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1. Published Event Examples . . . . . . . . . . . . . . . . 76
4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 76
4.1.2. Changing A Published Event . . . . . . . . . . . . . 77
4.1.3. Canceling A Published Event . . . . . . . . . . . . . 77
4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 78
4.1.5. Anniversaries or Events attached to entire days . . . 79
4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 80
4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 81
4.2.2. Reply To A Group Event Request . . . . . . . . . . . 81
4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 82
4.2.4. Countering an Event Proposal . . . . . . . . . . . . 83
4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 85
4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 87
4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 88
4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 89
4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 89
4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 91
4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 92
4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 93
4.3.1. Publish Busy Time . . . . . . . . . . . . . . . . . . 93
4.3.2. Request Busy Time . . . . . . . . . . . . . . . . . . 94
4.3.3. Reply To A Busy Time Request . . . . . . . . . . . . 95
4.4. Recurring Event and Time Zone Examples . . . . . . . . . 95
4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 95
4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 97
4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 99
4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 100
4.4.5. Change All Future Instances . . . . . . . . . . . . . 100
4.4.6. Add A New Instance To A Recurring Event . . . . . . . 101
4.4.7. Add A New Series of Instances To A Recurring Event . 102
4.4.8. Refreshing A Recurring Event . . . . . . . . . . . . 104
4.4.9. Counter An Instance Of A Recurring Event . . . . . . 106
4.4.10. Error Reply To A Request . . . . . . . . . . . . . . 107
4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 109
4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 110
4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 110
4.5.3. A VTODO Request for Updated Status . . . . . . . . . 111
4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 111
4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 112
4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 112
4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 113
4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 114
4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 114
4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 114
4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 115
5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 118 3.4. Methods for VTODO Components ..............................44
5.1. Partial Implementation . . . . . . . . . . . . . . . . . 118 3.4.1. PUBLISH ............................................44
5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 118 3.4.2. REQUEST ............................................46
5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 120 3.4.3. REPLY ..............................................51
5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 121 3.4.4. ADD ................................................53
5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 123 3.4.5. CANCEL .............................................55
5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 124 3.4.6. REFRESH ............................................57
5.2.1. Cancellation of an Unknown Calendar Component. . . . 124 3.4.7. COUNTER ............................................59
5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 125 3.4.8. DECLINECOUNTER .....................................61
5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 125 3.5. Methods for VJOURNAL Components ...........................62
6. Security Considerations . . . . . . . . . . . . . . . . . . . 125 3.5.1. PUBLISH ............................................63
6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 125 3.5.2. ADD ................................................64
6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 125 3.5.3. CANCEL .............................................66
6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 125 3.6. Status Replies ............................................68
6.1.3. Unauthorized Replacement of the Organizer . . . . . . 126 3.7. Implementation Considerations .............................77
6.1.4. Eavesdropping and Data Integrity . . . . . . . . . . 126 3.7.1. Working With Recurrence Instances ..................77
6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 126 3.7.2. Attendee Property Considerations ...................78
6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 126 3.7.3. Extension Tokens ...................................79
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 126 4. Examples .......................................................79
6.2.1. Securing iTIP transactions . . . . . . . . . . . . . 126 4.1. Published Event Examples ..................................79
6.2.2. Implementation Controls . . . . . . . . . . . . . . . 127 4.1.1. A Minimal Published Event ..........................80
6.2.3. Access Controls and Filtering . . . . . . . . . . . . 127 4.1.2. Changing a Published Event .........................80
6.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 127 4.1.3. Canceling a Published Event ........................81
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 128 4.1.4. A Rich Published Event .............................81
7.1. Registration Template for REQUEST-STATUS Values . . . . . 128 4.1.5. Anniversaries or Events Attached to Entire Days ....83
7.2. Additions to iCalendar METHOD Registry . . . . . . . . . 128 4.2. Group Event Examples ......................................83
7.3. REQUEST-STATUS Value Registry . . . . . . . . . . . . . . 129 4.2.1. A Group Event Request ..............................84
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 130 4.2.2. Reply to a Group Event Request .....................85
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 131 4.2.3. Update an Event ....................................85
9.1. Normative References . . . . . . . . . . . . . . . . . . 131 4.2.4. Countering an Event Proposal .......................86
9.2. Informative References . . . . . . . . . . . . . . . . . 131 4.2.5. Delegating an Event ................................88
Appendix A. Differences from RFC 2446 . . . . . . . . . . . . . 131 4.2.6. Delegate Accepts the Meeting .......................90
A.1. Changed Restrictions . . . . . . . . . . . . . . . . . . 131 4.2.7. Delegate Declines the Meeting ......................91
A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 132 4.2.8. Forwarding an Event Request ........................92
Appendix B. Change History (to be removed prior to 4.2.9. Cancel a Group Event ...............................92
publication as an RFC) . . . . . . . . . . . . . . . 132 4.2.10. Removing Attendees ................................93
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 135 4.2.11. Replacing the Organizer ...........................95
4.3. Busy Time Examples ........................................96
4.3.1. Publish Busy Time ..................................96
4.3.2. Request Busy Time ..................................96
4.3.3. Reply to a Busy Time Request .......................97
4.4. Recurring Event and Time Zone Examples ....................98
4.4.1. A Recurring Event Spanning Time Zones ..............98
4.4.2. Modify a Recurring Instance ........................99
4.4.3. Cancel an Instance ................................101
4.4.4. Cancel a Recurring Event ..........................101
4.4.5. Change All Future Instances .......................102
4.4.6. Add a New Instance to a Recurring Event ...........102
4.4.7. Add a New Series of Instances to a
Recurring Event ...................................103
4.4.8. Refreshing a Recurring Event ......................104
4.4.9. Counter an Instance of a Recurring Event ..........106
4.4.10. Error Reply to a Request .........................107
4.5. Group To-Do Examples .....................................108
4.5.1. A VTODO Request ...................................109
4.5.2. A VTODO Reply .....................................110
4.5.3. A VTODO Request for Updated Status ................110
4.5.4. A Reply: Percent-Complete .........................111
4.5.5. A Reply: Completed ................................111
4.5.6. An Updated VTODO Request ..........................112
4.5.7. Recurring VTODOs ..................................112
4.6. Journal Examples .........................................113
4.7. Other Examples ...........................................114
4.7.1. Event Refresh .....................................114
4.7.2. Bad RECURRENCE-ID .................................114
5. Application Protocol Fallbacks ................................116
5.1. Partial Implementation ...................................116
5.1.1. Event-Related Fallbacks ...........................117
5.1.2. Free/Busy-Related Fallbacks .......................119
5.1.3. To-Do-Related Fallbacks ...........................120
5.1.4. Journal-Related Fallbacks .........................122
5.2. Latency Issues ...........................................123
5.2.1. Cancellation of an Unknown Calendar Component .....123
5.2.2. Unexpected Reply from an Unknown Delegate .........124
5.3. Sequence Number ..........................................124
6. Security Considerations .......................................124
6.1. Security Threats .........................................124
6.1.1. Spoofing the Organizer ............................124
6.1.2. Spoofing the Attendee .............................124
6.1.3. Unauthorized Replacement of the Organizer .........125
6.1.4. Eavesdropping and Data Integrity ..................125
6.1.5. Flooding a Calendar ...............................125
6.1.6. Unauthorized REFRESH Requests .....................125
6.2. Recommendations ..........................................125
6.2.1. Securing iTIP transactions ........................125
6.2.2. Implementation Controls ...........................126
6.2.3. Access Controls and Filtering .....................126
6.3. Privacy Issues ...........................................126
7. IANA Considerations ...........................................127
7.1. Registration Template for REQUEST-STATUS Values ..........127
7.2. Additions to iCalendar METHOD Registry ...................127
7.3. REQUEST-STATUS Value Registry ............................129
8. Acknowledgments ...............................................130
9. References ....................................................131
9.1. Normative References .....................................131
9.2. Informative References ...................................131
Appendix A. Differences from RFC 2446 ...........................132
A.1. Changed Restrictions .....................................132
A.2. Deprecated Features ......................................133
1. Introduction and Overview 1. Introduction and Overview
This document specifies how calendaring systems use iCalendar This document specifies how calendaring systems use iCalendar
[RFC5545] objects to interoperate with other calendaring systems. In [RFC5545] objects to interoperate with other calendaring systems. In
particular, it specifies how to schedule events, to-dos, or daily particular, it specifies how to schedule events, to-dos, or daily
journal entries. It further specifies how to search for available journal entries. It further specifies how to search for available
busy time information. It does so in a general way without busy time information. It does so in a general way, without
specifying how communication between different systems actually takes specifying how communication between different systems actually takes
place. Subsequent documents specify transport bindings between place. Subsequent documents will specify transport bindings between
systems that use this protocol. systems that use this protocol.
This protocol is based on messages sent from an originator to one or This protocol is based on messages sent from an originator to one or
more recipients. For certain types of messages, a recipient may more recipients. For certain types of messages, a recipient may
reply, in order to update their status and may also return reply in order to update their status and may also return
transaction/request status information. The protocol supports the transaction/request status information. The protocol supports the
ability for the message originator to modify or cancel the original ability for the message originator to modify or cancel the original
message. The protocol also supports the ability for recipients to message. The protocol also supports the ability for recipients to
suggest changes to the originator of a message. The elements of the suggest changes to the originator of a message. The elements of the
protocol also define the user roles for its transactions. protocol also define the user roles for its transactions.
This specification obsoletes RFC 2446 - a list of important changes This specification obsoletes RFC 2446 - a list of important changes
is provided in Appendix A. is provided in Appendix A.
1.1. Formatting Conventions 1.1. Formatting Conventions
skipping to change at page 6, line 42 skipping to change at page 5, line 46
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Calendaring and scheduling roles are referred to in quoted-strings of Calendaring and scheduling roles are referred to in quoted-strings of
text with the first character of each word in upper case. For text with the first character of each word in upper case. For
example, "Organizer" refers to a role of a "Calendar User" (CU) example, "Organizer" refers to a role of a "Calendar User" (CU)
within the scheduling protocol. within the scheduling protocol.
Calendar components defined by [RFC5545] are referred to with Calendar components defined by [RFC5545] are referred to with
capitalized, quoted-strings of text. All calendar components start capitalized, quoted-strings of text. All calendar components start
with the letter "V". For example, "VEVENT" refers to the event with the letter "V". For example, "VEVENT" refers to the event
calendar component, "VTODO" refers to the to-do calendar component calendar component, "VTODO" refers to the to-do calendar component,
and "VJOURNAL" refers to the daily journal calendar component. and "VJOURNAL" refers to the daily journal calendar component.
Scheduling methods are referred to with capitalized, quoted-strings Scheduling methods are referred to with capitalized, quoted-strings
of text. For example, "REQUEST" refers to the method for requesting of text. For example, "REQUEST" refers to the method for requesting
a scheduling calendar component be created or modified, "REPLY" a scheduling calendar component be created or modified; "REPLY"
refers to the method a recipient of a request uses to update their refers to the method a recipient of a request uses to update their
status with the "Organizer" of the calendar component. status with the "Organizer" of the calendar component.
Properties defined by [RFC5545] are referred to with capitalized, Properties defined by [RFC5545] are referred to with capitalized,
quoted-strings of text, followed by the word "property". For quoted-strings of text, followed by the word "property". For
example, "ATTENDEE" property refers to the iCalendar property used to example, "ATTENDEE" property refers to the iCalendar property used to
convey the calendar address of a "Calendar User". convey the calendar address of a "Calendar User".
Property parameters defined by this specification are referred to Property parameters defined by this specification are referred to
with capitalized, quoted-strings of text, followed by the word with capitalized, quoted-strings of text, followed by the word
skipping to change at page 7, line 25 skipping to change at page 6, line 34
In tables, the quoted-string text is specified without quotes in In tables, the quoted-string text is specified without quotes in
order to minimize the table length. order to minimize the table length.
1.2. Related Documents 1.2. Related Documents
Implementers will need to be familiar with several other Implementers will need to be familiar with several other
specifications that, along with this one, describe the Internet specifications that, along with this one, describe the Internet
calendaring and scheduling standards. The related documents are: calendaring and scheduling standards. The related documents are:
[RFC5545] - specifies the objects, data types, properties and [RFC5545] - specifies the objects, data types, properties, and
property parameters used in the protocols, along with the methods property parameters used in the protocols, along with the methods
for representing and encoding them. for representing and encoding them.
[I-D.ietf-calsify-rfc2447bis] specifies an Internet email binding [iMIP] - specifies an Internet email binding for iTIP.
for iTIP.
This specification does not attempt to repeat the concepts or This specification does not attempt to repeat the concepts or
definitions from these other specifications. Where possible, definitions from these other specifications. Where possible,
explicit references are made to the other specifications. explicit references are made to the other specifications.
1.3. Roles 1.3. Roles
Exchanges of iCalendar objects for the purposes of group calendaring Exchanges of iCalendar objects for the purposes of group calendaring
and scheduling occur between "Calendar Users" (CUs). CUs take on and scheduling occur between "Calendar Users" (CUs). CUs take on
several roles in iTIP: several roles in iTIP:
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Role | Description | | Role | Description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Organizer | The CU who initiates an exchange takes on the role of | | Organizer | The CU who initiates an exchange takes on the role of |
| | "Organizer". For example, the CU who proposes a | | | Organizer. For example, the CU who proposes a group |
| | group meeting is the "Organizer". | | | meeting is the Organizer. |
| | | | | |
| Attendee | CUs who are included in the scheduling message as | | Attendee | CUs who are included in the scheduling message as |
| | possible recipients of that scheduling message. For | | | possible recipients of that scheduling message. For |
| | example, the CUs asked to participate in a group | | | example, the CUs asked to participate in a group |
| | meeting by the "Organizer" take on the role of | | | meeting by the Organizer take on the role of |
| | "Attendee". | | | Attendee. |
| | | | | |
| Other CU | A CU that is not explicitly included in a scheduling | | Other CU | A CU that is not explicitly included in a scheduling |
| | message, i.e., not the "Organizer" or an "Attendee". | | | message, i.e., not the Organizer or an Attendee. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Note that "ROLE" is also a descriptive parameter to the iCalendar Note that "ROLE" is also a descriptive parameter to the iCalendar
"ATTENDEE" property. Its use is to convey descriptive context about "ATTENDEE" property. Its use is to convey descriptive context about
an "Attendee" such as "chair", "required participant" or "non- an "Attendee" -- such as "chair", "required participant", or "non-
required participant" and has nothing to do with the calendaring required participant" -- and has nothing to do with the calendaring
workflow. workflow.
1.4. Methods 1.4. Methods
The iTIP methods are listed below and their usage and semantics are The iTIP methods are listed below and their usage and semantics are
defined in section 3 of this document. defined in Section 3 of this document.
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Method | Description | | Method | Description |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| PUBLISH | Used to publish an iCalendar object to one or | | PUBLISH | Used to publish an iCalendar object to one or |
| | more Calendar Users. There is no interactivity | | | more "Calendar Users". There is no |
| | between the publisher and any other calendar | | | interactivity between the publisher and any |
| | user. An example might include a baseball team | | | other "Calendar User". An example might include |
| | publishing its schedule to the public. | | | a baseball team publishing its schedule to the |
| | public. |
| | | | | |
| REQUEST | Used to schedule an iCalendar object with other | | REQUEST | Used to schedule an iCalendar object with other |
| | Calendar Users. Requests are interactive in | | | "Calendar Users". Requests are interactive in |
| | that they require the receiver to respond using | | | that they require the receiver to respond using |
| | the reply methods. Meeting requests, busy time | | | the reply methods. Meeting requests, busy-time |
| | requests and the assignment of tasks to other | | | requests, and the assignment of tasks to other |
| | Calendar Users are all examples. Requests are | | | "Calendar Users" are all examples. Requests are |
| | also used by the "Organizer" to update the | | | also used by the Organizer to update the status |
| | status of an iCalendar object. | | | of an iCalendar object. |
| | | | | |
| REPLY | A reply is used in response to a request to | | REPLY | A reply is used in response to a request to |
| | convey "Attendee" status to the "Organizer". | | | convey Attendee status to the Organizer. |
| | Replies are commonly used to respond to meeting | | | Replies are commonly used to respond to meeting |
| | and task requests. | | | and task requests. |
| | | | | |
| ADD | Add one or more new instances to an existing | | ADD | Add one or more new instances to an existing |
| | recurring iCalendar object. | | | recurring iCalendar object. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | iCalendar object. | | | iCalendar object. |
| | | | | |
| REFRESH | The Refresh method is used by an "Attendee" to | | REFRESH | Used by an Attendee to request the latest |
| | request the latest version of an iCalendar | | | version of an iCalendar object. |
| | object. |
| | | | | |
| COUNTER | The Counter method is used by an "Attendee" to | | COUNTER | Used by an Attendee to negotiate a change in an |
| | negotiate a change in an iCalendar object. | | | iCalendar object. Examples include the request |
| | Examples include the request to change a | | | to change a proposed event time or change the |
| | proposed event time or change the due date for a | | | due date for a task. |
| | task. |
| | | | | |
| DECLINECOUNTER | Used by the "Organizer" to decline the proposed | | DECLINECOUNTER | Used by the Organizer to decline the proposed |
| | counter-proposal. | | | counter proposal. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
Group scheduling in iTIP is accomplished using the set of "request" Group scheduling in iTIP is accomplished using the set of "request"
and "response" methods described above. The following table shows and "response" methods described above. The following table shows
the methods broken down by who can send them. the methods broken down by who can send them.
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Originator | Methods | | Originator | Methods |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER | | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER |
| | | | | |
| Attendee | REPLY, REFRESH, COUNTER, REQUEST (only when | | Attendee | REPLY, REFRESH, COUNTER, REQUEST (only when |
skipping to change at page 9, line 42 skipping to change at page 9, line 25
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
Note that for some calendar component types, the allowable methods Note that for some calendar component types, the allowable methods
are a subset of the above set. In addition, apart from "VTIMEZONE" are a subset of the above set. In addition, apart from "VTIMEZONE"
iCalendar components, only one component type is allowed in a single iCalendar components, only one component type is allowed in a single
iTIP message. iTIP message.
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 listed sender and receiver to accomplish the scheduling transactions listed
above. The Transport Protocol defines how the iCalendar objects are above. The transport protocol defines how the iCalendar objects are
sent between the sender and receiver. This document focuses on the sent between the sender and receiver. This document focuses on the
Application Protocol. Binding documents such as application protocol. Binding documents such as [iMIP] focus on the
[I-D.ietf-calsify-rfc2447bis] focus on the Transport Protocol. transport protocol.
The connection between Sender and Receiver in the diagram below The connection between sender and receiver in the diagram below
refers to the Application Protocol. The iCalendar objects passed refers to the application protocol. The iCalendar objects passed
from the Sender to the Receiver are presented in Section 3, from the sender to the receiver are presented in Section 3,
Application Protocol Elements. "Application Protocol Elements".
+----------+ +----------+ +----------+ +----------+
| | 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). "Calendar Service" (CS).
The architecture of iTIP is depicted in the diagram below. An The architecture of iTIP is depicted in the diagram below. An
application written to this specification may work with bindings for application written to this specification may work with bindings for
the store-and-forward transport, the real time transport, or both. the store-and-forward transport, the real-time transport, or both.
Also note that iTIP could be bound to other transports. Also note that iTIP could be bound to other transports.
+--------------------------------------------------------+ +--------------------------------------------------------+
| iTIP Protocol | | iTIP Protocol |
+--------------------------------------------------------+ +--------------------------------------------------------+
| Transport | | Transport |
+ - - - - - + - - - - - - + - - - - - + + - - - - - + - - - - - - + - - - - - +
| Real-time | Store-and-Forward | Others | | Real-Time | Store-and-Forward | Others |
+-----------------+--------------------+-----------------+ +-----------------+--------------------+-----------------+
2.1. Application Protocol 2.1. Application Protocol
In the iTIP model, an iCalendar object is created and managed by an In the iTIP model, an iCalendar object is created and managed by an
"Organizer". The "Organizer" interacts with other CUs by sending one "Organizer". The "Organizer" interacts with other CUs by sending one
or more of the iTIP messages listed above. "Attendees" use the or more of the iTIP messages listed above. "Attendees" use the
"REPLY" method to communicate their status. "Attendees" do not make "REPLY" method to communicate their status. "Attendees" do not make
direct changes to the master iCalendar object. They can, however, direct changes to the master iCalendar object. They can, however,
use the "COUNTER" method to suggest changes to the "Organizer". In use the "COUNTER" method to suggest changes to the "Organizer". In
skipping to change at page 11, line 10 skipping to change at page 10, line 35
There are two distinct states relevant to iCalendar objects used in There are two distinct states relevant to iCalendar objects used in
scheduling: the overall state of the iCalendar object and the state scheduling: the overall state of the iCalendar object and the state
associated with an "Attendee" in that iCalendar object. associated with an "Attendee" in that iCalendar object.
The state of an iCalendar object is defined by the "STATUS" property The state of an iCalendar object is defined by the "STATUS" property
and is controlled by the "Organizer." There is no default value for and is 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 iCalendar object. the appropriate value for each iCalendar object.
The state of a particular "Attendee" relative to a iCalendar object The state of a particular "Attendee" relative to an iCalendar object
used for scheduling is defined by the "PARTSTAT" parameter in the used for scheduling is defined by the "PARTSTAT" parameter in the
"ATTENDEE" property for each "Attendee". When an "Organizer" issues "ATTENDEE" property for each "Attendee". When an "Organizer" issues
the initial iCalendar object, "Attendee" status is typically unknown. the initial iCalendar object, "Attendee" status is typically unknown.
The "Organizer" specifies this by setting the "PARTSTAT" parameter to The "Organizer" specifies this by setting the "PARTSTAT" parameter to
"NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" property "NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" property
"PARTSTAT" parameter to an appropriate value as part of a "REPLY" "PARTSTAT" parameter to an appropriate value as part of a "REPLY"
message sent back to the "Organizer". message sent back to the "Organizer".
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". These steps are detailed in the "Attendee" informs the "Organizer". These steps are detailed in the
REQUEST method section. "REQUEST" method sections for the appropriate components.
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 In many organizations, one user will act on behalf of another to
organize and/or respond to meeting requests. iTIP provides two organize and/or respond to meeting requests. iTIP provides two
mechanisms that support these activities. mechanisms that 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
calendar users attending the meeting. Additionally, iCalendar from "Calendar Users" attending the meeting. Additionally, iCalendar
provides descriptive roles for each "Attendee". For instance, a role provides descriptive roles for each "Attendee". For instance, a role
of "chair" may be ascribed to one or more "Attendees". The "chair" of "chair" may be ascribed to one or more "Attendees". The "chair"
and the "Organizer" may or may not be the same calendar user. This and the "Organizer" may or may not be the same "Calendar User". This
maps well to scenarios where an assistant may manage meeting maps well to scenarios where an assistant may manage meeting
logistics for another individual who chairs a meeting. logistics for another individual who chairs a meeting.
Second, a "SENT-BY" parameter may be specified in either the Second, a "SENT-BY" parameter may be specified in either the
"Organizer" or "Attendee" properties. When specified, the "SENT-BY" "Organizer" or "Attendee" properties. When specified, the "SENT-BY"
parameter indicates that the responding CU acted on behalf of the parameter indicates that the responding CU acted on behalf of the
specified "Attendee" or "Organizer". specified "Attendee" or "Organizer".
2.1.4. Component Revisions 2.1.4. Component Revisions
skipping to change at page 12, line 37 skipping to change at page 12, line 22
o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
value is incremented according to the rules stated above. value is incremented according to the rules stated above.
o The "SEQUENCE" property value MUST be incremented each time the o The "SEQUENCE" property value MUST be incremented each time the
"Organizer" uses the "ADD" or "CANCEL" methods. "Organizer" uses the "ADD" or "CANCEL" methods.
o The "SEQUENCE" property value MUST NOT be incremented when using o The "SEQUENCE" property value MUST NOT be incremented when using
"REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
delegation "REQUEST". delegation "REQUEST".
In some circumstances the "Organizer" may not have received responses In some circumstances, the "Organizer" may not have received
to the final revision sent out. In this situation, the "Organizer" responses to the final revision sent out. In this situation, the
may wish to send an update "REQUEST", and set "RSVP=TRUE" for all "Organizer" may wish to send an update "REQUEST" and set "RSVP=TRUE"
"Attendees", so that current responses can be collected. for all "Attendees" so that current responses can be collected.
The value of the "SEQUENCE" property contained in a response from an The value of the "SEQUENCE" property contained in a response from an
"Attendee" may not always match the "Organizer's" revision. "Attendee" may not always match the "Organizer's" revision.
Implementations may choose to have the CUA indicate to the CU that Implementations may choose to have the CUA indicate to the CU that
the response is to an iCalendar object that has been revised and the response is to an iCalendar object that has been revised, and
allow the CU to decide whether or not to accept the response. allow the CU to decide whether or not to accept the response.
Whilst a change in sequence number is indicative of a significant Whilst a change in sequence number is indicative of a significant
change to a previously scheduled item, "Attendee" CUAs SHOULD NOT change to a previously scheduled item, "Attendee" CUAs SHOULD NOT
rely solely on a change in sequence number as a means of detecting a rely solely on a change in sequence number as a means of detecting a
significant change. Instead CUAs SHOULD compare the old and new significant change. Instead, CUAs SHOULD compare the old and new
versions of the calendar components and determine the exact nature of versions of the calendar components, determine the exact nature of
the changes and make decisions, possibly based on calendar user the changes, and make decisions -- possibly based on "Calendar User"
preferences, as to whether the user needs to be explicitly informed preferences -- as to whether the user needs to be explicitly informed
of the change. of the change.
2.1.5. Message Sequencing 2.1.5. Message Sequencing
CUAs that handle the iTIP application protocol must often correlate a CUAs that handle the iTIP application protocol must often correlate a
component in a calendar store with a component received in the iTIP component in a calendar store with a component received in the iTIP
message. For example, an event may be updated with a later revision message. For example, an event may be updated with a later revision
of the same event. To accomplish this, a CUA must correlate the of the same event. To accomplish this, a CUA must correlate the
version of the event already in its calendar store with the version version of the event already in its calendar store with the version
sent in the iTIP message. In addition to this correlation, there are sent in the iTIP message. In addition to this correlation, there are
several factors that can cause iTIP messages to arrive in an several factors that can cause iTIP messages to arrive in an
unexpected order. That is, an "Organizer" could receive a reply to unexpected order. That is, an "Organizer" could receive a reply to
an earlier revision of a component AFTER receiving a reply to a later an earlier revision of a component after receiving a reply to a later
revision. revision.
To maximize interoperability and to handle messages that arrive in an To maximize interoperability and to handle messages that arrive in an
unexpected order, use the following rules: unexpected order, use the following rules:
1. The primary key for referencing a particular iCalendar component 1. The primary key for referencing a particular iCalendar component
is the "UID" property value. To reference an instance of a is the "UID" property value. To reference an instance of a
recurring component, the primary key is composed of the "UID" and recurring component, the primary key is composed of the "UID" and
the "RECURRENCE-ID" properties. the "RECURRENCE-ID" properties.
skipping to change at page 14, line 36 skipping to change at page 14, line 22
| 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 |
| DECLINECOUNTER | Yes | Yes | No | No | | DECLINECOUNTER | Yes | Yes | No | No |
+----------------+--------+-------+----------+-----------+ +----------------+--------+-------+----------+-----------+
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 optional, and others are excluded. The restrictions are expressed in
this document using a simple "restriction table". The first column this document using a simple "restriction table". The first column
indicates the name of a component or property. Properties of the indicates the name of a component or property. Properties of the
iCalendar object are not indented. Properties of a component are iCalendar object are not indented. Properties of a component are
indented. The second column (the "Presence" column) indicates indented. The second column (the "Presence" column) indicates
whether a component or property should be present or not, and if whether or not a component or property should be present and, if
present how many times it can occur. The third column contains present, how many times it can occur. The third column contains
comments for further clarification. comments for further clarification.
The presence column uses the following values to assert whether a The presence column uses the following values to assert whether a
property is required, is optional and the number of times it may property is required or optional, and the number of times it may
appear in the iCalendar object. appear in the iCalendar object.
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Presence Value | Description | | Presence Value | Description |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| 1 | One instance MUST be present | | 1 | One instance MUST be present. |
| 1+ | At least one instance MUST be present | | 1+ | At least one instance MUST be present. |
| 0 | Instances of this property MUST NOT be present | | 0 | Instances of this property MUST NOT be present. |
| 0+ | Multiple instances MAY be present | | 0+ | Multiple instances MAY be present. |
| 0 or 1 | Up to 1 instance of this property MAY be present | | 0 or 1 | Up to 1 instance of this property MAY be |
| | present. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA- The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA-
COMPONENT" and "X-COMPONENT" to show where registered and vendor- COMPONENT", and "X-COMPONENT" to show where registered and
specific property and component extensions can appear. The tables do experimental property and component extensions can appear. The
not lay out the restrictions of property parameters. Those tables do not lay out the restrictions of property parameters. Those
restrictions are defined in [RFC5545]. restrictions are defined in [RFC5545].
3.1. Common Component Restriction Tables 3.1. Common Component Restriction Tables
3.1.1. VCALENDAR 3.1.1. VCALENDAR
The restriction table below applies to properties of the iCalendar The restriction table below applies to properties of the iCalendar
object. That is, the properties at the outermost scope. object. That is, the properties at the outermost scope.
+-----------------------------------------------------+ +-----------------------------------------------------+
| Constraints for properties in a VCALENDAR Component | | Constraints for Properties in a VCALENDAR Component |
+-----------------------------------------------------+ +-----------------------------------------------------+
+--------------------+----------+---------------------+ +--------------------+----------+--------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+---------------------+ +--------------------+----------+--------------------+
| CALSCALE | 0 or 1 | | | CALSCALE | 0 or 1 | |
| PRODID | 1 | | | PRODID | 1 | |
| VERSION | 1 | Value MUST be "2.0" | | VERSION | 1 | Value MUST be 2.0. |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
+--------------------+----------+---------------------+ +--------------------+----------+--------------------+
3.1.2. VTIMEZONE 3.1.2. VTIMEZONE
"VTIMEZONE" components may be referred to by other components via a "VTIMEZONE" components may be referred to by other components via a
"TZID" parameter on a "DATETIME" value type. The property "TZID" parameter on a "DATETIME" value type. The property
restrictions in the table below apply to any "VTIMEZONE" component in restrictions in the table below apply to any "VTIMEZONE" component in
an iTIP message. an iTIP message.
+--------------------------------------+ +--------------------------------------+
| Constraints for VTIMEZONE Components | | Constraints for VTIMEZONE Components |
+--------------------------------------+ +--------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to timezone | | | | refers to timezone. |
| DAYLIGHT | 0+ | MUST be one or more of either | | DAYLIGHT | 0+ | MUST be one or more of either |
| | | STANDARD or DAYLIGHT | | | | STANDARD or DAYLIGHT. |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| DTSTART | 1 | MUST be local time format | | DTSTART | 1 | MUST be local time format. |
| RDATE | 0+ | | | RDATE | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| TZNAME | 0+ | | | TZNAME | 0+ | |
| TZOFFSETFROM | 1 | | | TZOFFSETFROM | 1 | |
| TZOFFSETTO | 1 | | | TZOFFSETTO | 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| STANDARD | 0+ | MUST be one or more of either | | STANDARD | 0+ | MUST be one or more of either |
| | | STANDARD or DAYLIGHT | | | | STANDARD or DAYLIGHT. |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| DTSTART | 1 | MUST be local time format | | DTSTART | 1 | MUST be local time format. |
| RDATE | 0+ | if present RRULE MUST NOT be | | RDATE | 0+ | If present, RRULE MUST NOT be |
| | | present | | | | present. |
| RRULE | 0 or 1 | if present RDATE MUST NOT be | | RRULE | 0 or 1 | If present, RDATE MUST NOT be |
| | | present | | | | present. |
| TZNAME | 0+ | | | TZNAME | 0+ | |
| TZOFFSETFROM | 1 | | | TZOFFSETFROM | 1 | |
| TZOFFSETTO | 1 | | | TZOFFSETTO | 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| TZID | 1 | | | TZID | 1 | |
| TZURL | 0 or 1 | | | TZURL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 17, line 13 skipping to change at page 17, line 22
+-----------------------------------+ +-----------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| VALARM | 0+ | | | VALARM | 0+ | |
| ACTION | 1 | | | ACTION | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| ATTENDEE | 0+ | | | ATTENDEE | 0+ | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DURATION | 0 or 1 | if present REPEAT MUST be present | | DURATION | 0 or 1 | If present, REPEAT MUST be |
| REPEAT | 0 or 1 | if present DURATION MUST be | | | | present. |
| | | present | | REPEAT | 0 or 1 | If present, DURATION MUST be |
| | | present. |
| SUMMARY | 0 or 1 | | | SUMMARY | 0 or 1 | |
| TRIGGER | 1 | | | TRIGGER | 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2. Methods for VEVENT Calendar Components 3.2. Methods for VEVENT Calendar Components
This section defines the property set restrictions for the method This section defines the property set restrictions for the method
types that are applicable to the "VEVENT" calendar component. Each types that are applicable to the "VEVENT" calendar component. Each
skipping to change at page 17, line 40 skipping to change at page 18, line 13
"VEVENT" calendar component. "VEVENT" calendar component.
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Method | Description | | Method | Description |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| PUBLISH | Post notification of an event. Used primarily | | PUBLISH | Post notification of an event. Used primarily |
| | as a method of advertising the existence of an | | | as a method of advertising the existence of an |
| | event. | | | event. |
| | | | | |
| REQUEST | Make a request for an event. This is an | | REQUEST | Make a request for an event. This is an |
| | explicit invitation to one or more "Attendees". | | | explicit invitation to one or more Attendees. |
| | Event requests are also used to update or change | | | Event requests are also used to update or change |
| | an existing event. Clients that cannot handle | | | an 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 a |
| | PUBLISH. | | | PUBLISH. |
| | | | | |
| REPLY | Reply to an event request. Clients may set | | REPLY | Reply to an event request. Clients may set |
| | their status ("PARTSTAT") to ACCEPTED, DECLINED, | | | their status (PARTSTAT) to ACCEPTED, DECLINED, |
| | 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 |
| | "Attendee" asking for the latest version of an | | | asking for the latest version of an event to be |
| | event to be resent to the requester. | | | 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 Attendee |
| | "Attendee" by the "Organizer". | | | by the Organizer. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
3.2.1. PUBLISH 3.2.1. PUBLISH
The "PUBLISH" method in a "VEVENT" calendar component is an The "PUBLISH" method in a "VEVENT" calendar component is an
unsolicited posting of an iCalendar object. Any CU may add published unsolicited posting of an iCalendar object. Any CU may add published
components to their calendar. The "Organizer" MUST be present in a components to their calendar. The "Organizer" MUST be present in a
published iCalendar component. "Attendees" MUST NOT be present. Its published iCalendar component. "Attendees" MUST NOT be present. Its
expected usage is for encapsulating an arbitrary event as an expected usage is for encapsulating an arbitrary event as an
iCalendar object. The "Organizer" may subsequently update (with iCalendar object. The "Organizer" may subsequently update (with
skipping to change at page 18, line 40 skipping to change at page 19, line 12
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+----------------------------------------------+ +----------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VEVENT | | Constraints for a METHOD:PUBLISH of a VEVENT |
+----------------------------------------------+ +----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST equal "PUBLISH" | | METHOD | 1 | MUST equal PUBLISH. |
| | | | | | | |
| VEVENT | 1+ | | | VEVENT | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SUMMARY | 1 | Can be null. | | SUMMARY | 1 | Can be null. |
| UID | 1 | | | UID | 1 | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| SEQUENCE | 0 or 1 | MUST be present if value is | | SEQUENCE | 0 or 1 | MUST be present if value is |
| | | greater than 0, MAY be present if | | | | greater than 0; MAY be present if |
| | | 0 | | | | 0. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0 or 1 | | | CONTACT | 0 or 1 | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null | | DESCRIPTION | 0 or 1 | Can be null. |
| DTEND | 0 or 1 | If present DURATION MUST NOT be | | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | If present DTEND MUST NOT be | | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | TENTATIVE/CONFIRMED/CANCELLED | | | | TENTATIVE/CONFIRMED/CANCELLED. |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
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:
o Invite "Attendees" to an event o Invite "Attendees" to an event.
o Reschedule an existing event
o Response to a REFRESH request o Reschedule an existing event.
o Update the details of an existing event, without rescheduling it
o Response to a "REFRESH" request.
o Update the details of an existing event, without rescheduling it.
o Update the status of "Attendees" of an existing event, without o Update the status of "Attendees" of an existing event, without
rescheduling it rescheduling it.
o Reconfirm an existing event, without rescheduling it
o Forward a "VEVENT" to another uninvited CU o Reconfirm an existing event, without rescheduling it.
o Forward a "VEVENT" to another uninvited CU.
o For an existing "VEVENT" calendar component, delegate the role of o For an existing "VEVENT" calendar component, delegate the role of
"Attendee" to another CU "Attendee" to another CU.
o For an existing "VEVENT" calendar component, changing the role of
"Organizer" to another CU o For an existing "VEVENT" calendar component, change the role of
"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 The "UID" and "SEQUENCE" properties are used to distinguish the
various uses of the "REQUEST" method. If the "UID" property value in 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 "VEVENT" calendar component. If the "UID" "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
property value is found on the recipient's calendar, then the property value is found on the recipient's calendar, then the
"REQUEST" is for a rescheduling, an update, or a reconfirm of the "REQUEST" is for a rescheduling, an update, or a reconfirmation of
"VEVENT" calendar component. the "VEVENT" calendar component.
For the "REQUEST" method, multiple "VEVENT" components in a single For the "REQUEST" method, multiple "VEVENT" components in a single
iCalendar object are only permitted when for components with the same iCalendar object are only permitted for components with the same
"UID" property. That is, a series of recurring events may have "UID" property. That is, a series of recurring events may have
instance-specific information. In this case, multiple "VEVENT" instance-specific information. In this case, multiple "VEVENT"
components are needed to express the entire series. components are needed to express the entire series.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+----------------------------------------------+ +----------------------------------------------+
| Constraints for a METHOD:REQUEST of a VEVENT | | Constraints for a METHOD:REQUEST of a VEVENT |
+----------------------------------------------+ +----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REQUEST" | | METHOD | 1 | MUST be REQUEST. |
| | | | | | | |
| VEVENT | 1+ | All components MUST have the same | | VEVENT | 1+ | All components MUST have the same |
| | | UID | | | | UID. |
| ATTENDEE | 1+ | | | ATTENDEE | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 0 or 1 | MUST be present if value is | | SEQUENCE | 0 or 1 | MUST be present if value is |
| | | greater than 0, MAY be present if | | | | greater than 0; MAY be present if |
| | | 0 | | | | 0. |
| SUMMARY | 1 | Can be null | | SUMMARY | 1 | Can be null. |
| UID | 1 | | | UID | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null | | DESCRIPTION | 0 or 1 | Can be null. |
| DTEND | 0 or 1 | if present DURATION MUST NOT be | | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | if present DTEND MUST NOT be | | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED | | STATUS | 0 or 1 | MAY be one of |
| | | TENTATIVE/CONFIRMED. |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
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 The "REQUEST" method may be used to reschedule an event. A
rescheduled event involves a change to the existing event in terms of rescheduled event involves a change to the existing event in terms of
its time or recurrence intervals and possibly the location or its time or recurrence intervals and possibly the location or
description. If the recipient CUA of a "REQUEST" method finds that description. If the recipient CUA of a "REQUEST" method finds that
the "UID" property value already exists on the calendar, but that the the "UID" property value already exists on the calendar but that the
"SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
greater than the value for the existing event, then the "REQUEST" greater than the value for the existing event, then the "REQUEST"
method describes a rescheduling of the event. method describes a rescheduling of 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 recurrence intervals, and might not involve a change to the location
or description for the event. If the recipient CUA of a "REQUEST" or description for the event. If the recipient CUA of a "REQUEST"
method finds that the "UID" property value already exists on the method finds that the "UID" property value already exists on the
calendar and that the "SEQUENCE" property value in the "REQUEST" is calendar and that the "SEQUENCE" property value in the "REQUEST" is
the same as the value for the existing event, then the "REQUEST" the same as the value for the existing event, then the "REQUEST"
method describes an update of the event details, but no rescheduling method describes an update of the event details, but not a
of the event. rescheduling of the event.
The update "REQUEST" method is the appropriate response to a The update "REQUEST" method is the appropriate response to a
"REFRESH" method sent from an "Attendee" to the "Organizer" of an "REFRESH" method sent from an "Attendee" to the "Organizer" of an
event. event.
The "Organizer" of an event may also send unsolicited "REQUEST" The "Organizer" of an event may also send unsolicited "REQUEST"
methods. The unsolicited "REQUEST" methods may be used to update the methods. The unsolicited "REQUEST" methods may be used to update the
details of the event without rescheduling it, to update the details of the event without rescheduling it, to update the
"PARTSTAT" parameter of "Attendees", or to reconfirm the event. "PARTSTAT" parameter of "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 Some calendar and scheduling systems allow "Attendees" to delegate
their presence at an event to another calendar user. iTIP supports their presence at an event to another "Calendar User". iTIP supports
this concept using the following workflow. Any "Attendee" may this concept using the following workflow. Any "Attendee" may
delegate their right to participate in a calendar VEVENT to another delegate their right to participate in a calendar "VEVENT" to another
CU. The implication is that the delegate participates in lieu of the CU. The implication is that the delegate participates in lieu of the
original "Attendee"; NOT in addition to the "Attendee". The original "Attendee", NOT in addition to the "Attendee". The
delegator MUST notify the "Organizer" of this action using the steps delegator MUST notify the "Organizer" of this action using the steps
outlined below. Implementations may support or restrict delegation outlined below. Implementations may support or restrict delegation
as they see fit. For instance, some implementations may restrict a as they see fit. For instance, some implementations may restrict a
delegate from delegating a "REQUEST" to another CU. delegate from delegating a "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 with the calendar address of the "Delegate". The "Delegator" MUST
also send a "REPLY" method to the "Organizer" with the "Delegator's" also send a "REPLY" method to the "Organizer" with the "Delegator's"
"ATTENDEE" property "PARTSTAT" parameter value set to "DELEGATED". "ATTENDEE" property "PARTSTAT" parameter value set to "DELEGATED".
In addition, the "DELEGATED-TO" parameter MUST be included with the In addition, the "DELEGATED-TO" parameter MUST be included with the
calendar address of the "Delegate". Also, a new "ATTENDEE" property calendar address of the "Delegate". Also, a new "ATTENDEE" property
for the "Delegate" MUST be included and must specify the calendar for the "Delegate" MUST be included and must specify the calendar
user address set in the "DELEGATED-TO" parameter, as above. user address set in the "DELEGATED-TO" parameter, as above.
In response to the request, the "Delegate" MUST send a "REPLY" method In response to the request, the "Delegate" MUST send a "REPLY" method
to the "Organizer" and optionally, to the "Delegator". The "REPLY" to the "Organizer", and optionally to the "Delegator". The "REPLY"
method SHOULD include the "ATTENDEE" property with the "DELEGATED- method SHOULD include the "ATTENDEE" property with the "DELEGATED-
FROM" parameter value of the "Delegator's" calendar address. FROM" parameter value of the "Delegator's" calendar address.
The "Delegator" may continue to receive updates to the event even The "Delegator" may continue to receive updates to the event even
though they will not be attending. This is accomplished by the though they will not be attending. This is accomplished by the
"Delegator" setting their "role" attribute to "NON-PARTICIPANT" in "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in
the "REPLY" to the "Organizer" the "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 The situation may arise where the "Organizer" of a "VEVENT" is no
longer able to perform the "Organizer" role and abdicates without longer able to perform the "Organizer" role and abdicates without
passing on the "Organizer" role to someone else. When this occurs passing on the "Organizer" role to someone else. When this occurs,
the "Attendees" of the VEVENT may use out-of-band mechanisms to the "Attendees" of the "VEVENT" may use out-of-band mechanisms to
communicate the situation and agree upon a new "Organizer". The new communicate the situation and agree upon a new "Organizer". The new
"Organizer" should then send out a new "REQUEST" with a modified "Organizer" should then send out a new "REQUEST" with a modified
version of the VEVENT in which the "SEQUENCE" number has been version of the "VEVENT" in which the "SEQUENCE" number has been
incremented and the "ORGANIZER" property has been changed to the new incremented and the "ORGANIZER" property has been changed to the new
"Organizer". "Organizer".
3.2.2.5. Sending on Behalf of the Organizer 3.2.2.5. Sending on Behalf of the Organizer
There are a number of scenarios that support the need for a calendar There are a number of scenarios that support the need for a "Calendar
user to act on behalf of the "Organizer" without explicit role User" to act on behalf of the "Organizer" without explicit role
changing. This might be the case if the CU designated as "Organizer" changing. This might be the case if the CU designated as "Organizer"
was sick or unable to perform duties associated with that function. is sick or unable to perform duties associated with that function.
In these cases iTIP supports the notion of one CU acting on behalf of In these cases, iTIP supports the notion of one CU acting on behalf
another. Using the "SENT-BY" parameter, a calendar user could send of another. Using the "SENT-BY" parameter, a "Calendar User" could
an updated "VEVENT" REQUEST. In the case where one CU sends on send an updated "VEVENT" "REQUEST". In the case where one CU sends
behalf of another CU, the "Attendee" responses are still directed on behalf of another CU, the "Attendee" responses are still directed
back towards the CU designated as "Organizer". back towards the CU designated as "Organizer".
3.2.2.6. Forwarding to An Uninvited CU 3.2.2.6. Forwarding to an Uninvited CU
An "Attendee" invited to a "VEVENT" calendar component may send the An "Attendee" invited to a "VEVENT" calendar component may send the
"VEVENT" calendar component to another new CU, not previously "VEVENT" calendar component to another new CU not previously
associated with the "VEVENT" calendar component. The current associated with the "VEVENT" calendar component. The current
"Attendee" invited to the "VEVENT" calendar component does this by "Attendee" invited to the "VEVENT" calendar component does this by
forwarding the original "REQUEST" method to the new CU. The new CU forwarding the original "REQUEST" method to the new CU. The new CU
can send a "REPLY" to the "Organizer" of the "VEVENT" calendar can send a "REPLY" to the "Organizer" of the "VEVENT" calendar
component. The reply contains an "ATTENDEE" property for the new CU. component. The reply contains an "ATTENDEE" property for the new CU.
The "Organizer" ultimately decides whether or not the new CU becomes The "Organizer" ultimately decides whether or not the new CU becomes
part of the event and is not obligated to do anything with a "REPLY" part of the event and is not obligated to do anything with a "REPLY"
from a new (uninvited) CU. If the "Organizer" does not want the new from a new (uninvited) CU. If the "Organizer" does not want the new
CU to be part of the event, the new "ATTENDEE" property is not added CU to be part of the event, the new "ATTENDEE" property is not added
skipping to change at page 24, line 37 skipping to change at page 25, line 15
something the "Organizer" considers appropriate. The "Organizer" something the "Organizer" considers appropriate. The "Organizer"
SHOULD send the new CU a "REQUEST" message to inform them that they SHOULD send the new CU a "REQUEST" message to inform them that they
have been added. have been added.
When forwarding a "REQUEST" to another CU, the forwarding "Attendee" When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
MUST NOT make changes to the original message. MUST NOT make changes to the original message.
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 The "Organizer" of an event may also request updated status from one
or more "Attendees. The "Organizer" sends a "REQUEST" method to the or 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 value. A recipient will determine that the only change in the
"REQUEST" is that their "RSVP" property parameter indicates a request "REQUEST" is that their "RSVP" property parameter indicates a request
for updated status. The recipient SHOULD respond with a "REPLY" for updated status. The recipient SHOULD respond with a "REPLY"
method indicating their current status with respect to the "REQUEST". method indicating 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 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 respond (e.g., accept or decline) to a "REQUEST" or to reply to a
delegation "REQUEST". When used to provide a delegation response, delegation "REQUEST". When used to provide a delegation response,
the "Delegator" SHOULD include the calendar address of the "Delegate" the "Delegator" SHOULD include the calendar address of the "Delegate"
on the "DELEGATED-TO" property parameter of the "Delegator's" on the "DELEGATED-TO" property parameter of the "Delegator's"
"ATTENDEE" property. The "Delegate" SHOULD include the calendar "ATTENDEE" property. The "Delegate" SHOULD include the calendar
address of the "Delegator" on the "DELEGATED-FROM" property parameter address of the "Delegator" on the "DELEGATED-FROM" property parameter
of the "Delegate's" "ATTENDEE" property. of the "Delegate's" "ATTENDEE" property.
The "REPLY" method is also used when processing of a "REQUEST" fails. The "REPLY" method is also used when processing of a "REQUEST" fails.
Depending on the value of the "REQUEST-STATUS" property no scheduling Depending on the value of the "REQUEST-STATUS" property, no
action may have been performed. scheduling action may have been performed.
The "Organizer" of an event may receive the "REPLY" method from a CU The "Organizer" of an event may receive the "REPLY" method from a CU
not in the original "REQUEST". For example, a "REPLY" may be not in the original "REQUEST". For example, a "REPLY" may be
received from a "Delegate" to an event. In addition, the "REPLY" received from a "Delegate" to an event. In addition, the "REPLY"
method may be received from an unknown CU (a "Party Crasher"). This method may be received from an unknown CU (a "Party Crasher"). This
uninvited "Attendee" may be accepted, or the "Organizer" may cancel uninvited "Attendee" may be accepted, or the "Organizer" may cancel
the event for the uninvited "Attendee" by sending a "CANCEL" method the event for the uninvited "Attendee" by sending a "CANCEL" method
to the uninvited "Attendee". to the uninvited "Attendee".
An "Attendee" MAY include a message to the "Organizer" using the An "Attendee" MAY include a message to the "Organizer" using the
skipping to change at page 25, line 32 skipping to change at page 26, line 12
acceptance and wants to let the "Organizer" know why, the reason can acceptance and wants to let the "Organizer" know why, the reason can
be expressed in the "COMMENT" property value. 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 "Attendees" may have another CU respond on their behalf. This is
done using the "SENT-BY" parameter. done using the "SENT-BY" parameter.
The optional properties listed in the table below (those listed as 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 "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 request. If property changes are desired, the "COUNTER" message must
used. be used.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+--------------------------------------------+ +--------------------------------------------+
| Constraints for a METHOD:REPLY of a VEVENT | | Constraints for a METHOD:REPLY of a VEVENT |
+--------------------------------------------+ +--------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REPLY" | | METHOD | 1 | MUST be REPLY. |
| | | | | | | |
| VEVENT | 1+ | All components MUST have the same | | VEVENT | 1+ | All components MUST have the same |
| | | UID | | | | UID. |
| ATTENDEE | 1 | MUST be the address of the | | ATTENDEE | 1 | MUST be the address of the |
| | | Attendee replying. | | | | Attendee replying. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| UID | 1 | MUST be the UID of the original | | UID | 1 | MUST be the UID of the original |
| | | REQUEST | | | | REQUEST. |
| SEQUENCE | 0 or 1 | MUST if non-zero, MUST be the | | SEQUENCE | 0 or 1 | If non-zero, MUST be the sequence |
| | | sequence number of the original | | | | number of the original REQUEST. |
| | | REQUEST. MAY be present if 0. | | | | MAY be present if 0. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DTEND | 0 or 1 | if present DURATION MUST NOT be | | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| DURATION | 0 or 1 | if present DTEND MUST NOT be | | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | | | STATUS | 0 or 1 | |
| SUMMARY | 0 or 1 | | | SUMMARY | 0 or 1 | |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 27, line 21 skipping to change at page 27, line 49
The "ADD" method allows the "Organizer" to add one or more new The "ADD" method allows the "Organizer" to add one or more new
instances to an existing "VEVENT" using a single iTIP message without instances to an existing "VEVENT" using a single iTIP message without
having to send the entire "VEVENT" with all the existing instance having to send the entire "VEVENT" with all the existing instance
data, as it would have to do if the "REQUEST" method were used. data, as it would have to do if the "REQUEST" method were used.
The "UID" must be that of the existing event. If the "UID" property The "UID" must be that of the existing event. If the "UID" property
value in the "ADD" is not found on the recipient's calendar, then the value in the "ADD" is not found on the recipient's calendar, then the
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 implementation does not support the "ADD" method, it should respond
with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
When handling an "ADD" message, the "Attendee" treats each component When handling an "ADD" message, the "Attendee" treats each component
in the "ADD" message as if it were referenced via an "RDATE"in the in the "ADD" message as if it were referenced via an "RDATE" in the
main component. main component.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+------------------------------------------+ +------------------------------------------+
| Constraints for a METHOD:ADD of a VEVENT | | Constraints for a METHOD:ADD of a VEVENT |
+------------------------------------------+ +------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "ADD" | | METHOD | 1 | MUST be ADD. |
| | | | | | | |
| VEVENT | 1 | | | VEVENT | 1 | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | MUST be greater than 0 | | SEQUENCE | 1 | MUST be greater than 0. |
| SUMMARY | 1 | Can be null | | SUMMARY | 1 | Can be null. |
| UID | 1 | MUST match that of the original | | UID | 1 | MUST match that of the original |
| | | event | | | | event. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| ATTENDEE | 0+ | | | ATTENDEE | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null | | DESCRIPTION | 0 or 1 | Can be null. |
| DTEND | 0 or 1 | if present DURATION MUST NOT be | | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | if present DTEND MUST NOT be | | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
| | | present | | | | present. |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED | | STATUS | 0 or 1 | MAY be one of |
| | | TENTATIVE/CONFIRMED. |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| EXDATE | 0 | | | EXDATE | 0 | |
| RECURRENCE-ID | 0 | | | RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| RDATE | 0 | | | RDATE | 0 | |
| RRULE | 0 | | | RRULE | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2.5. CANCEL 3.2.5. CANCEL
The "CANCEL" method in a "VEVENT" calendar component is used to send The "CANCEL" method in a "VEVENT" calendar component is used to send
a cancellation notice of an existing event request to the affected a cancellation notice of an existing event request to the affected
"Attendees". The message is sent by the "Organizer" of the event. "Attendees". The message is sent by the "Organizer" of the event.
For a recurring event, either the whole event or instances of an For a recurring event, either the whole event or instances of an
event may be cancelled. To cancel the complete range of recurring event may be cancelled. To cancel the complete range of a recurring
event, the "UID" property value for the event MUST be specified and a event, the "UID" property value for the event MUST be specified and a
"RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In
order to cancel an individual instance of the event, the order to cancel an individual instance of the event, the
"RECURRENCE-ID" property value for the event MUST be specified in the "RECURRENCE-ID" property value for the event MUST be specified in the
"CANCEL" method. "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 a. The "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
"THISANDFUTURE" to indicate cancellation of the specified "THISANDFUTURE" to indicate cancellation of the specified
"VEVENT" calendar component and all instances after; or "VEVENT" calendar component and all instances after.
b. individual recurrence instances may be cancelled by specifying
b. Individual recurrence instances may be cancelled by specifying
multiple "VEVENT" components each with a "RECURRENCE-ID" property multiple "VEVENT" components each with a "RECURRENCE-ID" property
corresponding to one of the instances to be cancelled. corresponding to one of the instances to be cancelled.
The "Organizer" MUST send a "CANCEL" message to each "Attendee" The "Organizer" MUST send a "CANCEL" message to each "Attendee"
affected by the cancellation. This can be done using a single affected by the cancellation. This can be done using a single
"CANCEL" message for all "Attendees", or multiple messages with "CANCEL" message for all "Attendees" or by using multiple messages
different subsets of the affected "Attendees" in each. with different subsets of the affected "Attendees" in each.
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
incremented as described in Section 2.1.4. incremented as described in Section 2.1.4.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+---------------------------------------------+ +---------------------------------------------+
| Constraints for a METHOD:CANCEL of a VEVENT | | Constraints for a METHOD:CANCEL of a VEVENT |
+---------------------------------------------+ +---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "CANCEL" | | METHOD | 1 | MUST be CANCEL. |
| | | | | | | |
| VEVENT | 1+ | All must have the same UID | | VEVENT | 1+ | All must have the same UID. |
| ATTENDEE | 0+ | MUST include some or all | | ATTENDEE | 0+ | MUST include some or all |
| | | "Attendees" being removed from | | | | Attendees being removed from the |
| | | the event. MUST include some or | | | | event. MUST include some or all |
| | | all "Attendees" if the entire | | | | Attendees if the entire event is |
| | | event is cancelled. | | | | cancelled. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | | | SEQUENCE | 1 | |
| UID | 1 | MUST be the UID of the original | | UID | 1 | MUST be the UID of the original |
| | | REQUEST | | | | REQUEST. |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DTEND | 0 or 1 | if present DURATION MUST NOT be | | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| DURATION | 0 or 1 | if present DTEND MUST NOT be | | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MUST be set to CANCELLED to | | STATUS | 0 or 1 | MUST be set to CANCELLED to |
| | | cancel the entire event. If | | | | cancel the entire event. If |
| | | uninviting specific "Attendees" | | | | uninviting specific Attendees, |
| | | then MUST NOT be included. | | | | then MUST NOT be included. |
| SUMMARY | 0 or 1 | | | SUMMARY | 0 or 1 | |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 31, line 27 skipping to change at page 32, line 12
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+----------------------------------------------+ +----------------------------------------------+
| Constraints for a METHOD:REFRESH of a VEVENT | | Constraints for a METHOD:REFRESH of a VEVENT |
+----------------------------------------------+ +----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REFRESH" | | METHOD | 1 | MUST be REFRESH. |
| | | | | | | |
| VEVENT | 1 | | | VEVENT | 1 | |
| ATTENDEE | 1 | MUST be the address of requester | | ATTENDEE | 1 | MUST be the address of requester. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| UID | 1 | MUST be the UID associated with | | UID | 1 | MUST be the UID associated with |
| | | original REQUEST | | | | original REQUEST. |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTACH | 0 | | | ATTACH | 0 | |
| CATEGORIES | 0 | | | CATEGORIES | 0 | |
| CLASS | 0 | | | CLASS | 0 | |
| CONTACT | 0 | | | CONTACT | 0 | |
| CREATED | 0 | | | CREATED | 0 | |
| DESCRIPTION | 0 | | | DESCRIPTION | 0 | |
| DTEND | 0 | | | DTEND | 0 | |
| DTSTART | 0 | | | DTSTART | 0 | |
skipping to change at page 32, line 40 skipping to change at page 33, line 25
| VFREEBUSY | 0 | | | VFREEBUSY | 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 "Attendee" of an existing event to submit to the "Organizer" a
counter proposal to the event. The "Attendee" sends this message to counter proposal to the event. 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 calendar component that provides the complete description of the
alternate event. alternate event.
The "Organizer" rejects the counter proposal by sending the The "Organizer" rejects the counter proposal by sending the
"Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
counter proposal by rescheduling the event as described in section counter proposal by rescheduling the event as described in
3.2.2.1 Rescheduling an Event. The "Organizers" CUA SHOULD send a Section 3.2.2.1, "Rescheduling an Event". The "Organizer's" CUA
"REQUEST" message to all "Attendees" affected by any change triggered SHOULD send a "REQUEST" message to all "Attendees" affected by any
by an accepted "COUNTER". change triggered by an accepted "COUNTER".
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+----------------------------------------------+ +----------------------------------------------+
| Constraints for a METHOD:COUNTER of a VEVENT | | Constraints for a METHOD:COUNTER of a VEVENT |
+----------------------------------------------+ +----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "COUNTER" | | METHOD | 1 | MUST be COUNTER. |
| | | | | | | |
| VEVENT | 1 | | | VEVENT | 1 | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | MUST be the "Organizer" of the | | ORGANIZER | 1 | MUST be the Organizer of the |
| | | original event | | | | original event. |
| SEQUENCE | 1 | MUST echo the original SEQUENCE | | SEQUENCE | 1 | MUST echo the original SEQUENCE |
| | | number. MUST be present if | | | | number. MUST be present if |
| | | non-zero. MAY be present if | | | | non-zero. MAY be present if |
| | | zero. | | | | zero. |
| SUMMARY | 1 | Can be null | | SUMMARY | 1 | Can be null. |
| UID | 1 | MUST be the UID associated with | | UID | 1 | MUST be the UID associated with |
| | | the REQUEST being countered | | | | the REQUEST being countered. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| ATTENDEE | 0+ | Can also be used to propose other | | ATTENDEE | 0+ | Can also be used to propose other |
| | | "Attendees" | | | | Attendees. |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DTEND | 0 or 1 | if present DURATION MUST NOT be | | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | if present DTEND MUST NOT be | | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | Value must be one of | | STATUS | 0 or 1 | Value must be one of |
| | | CONFIRMED/TENATIVE/CANCELLED | | | | CONFIRMED/TENATIVE/CANCELLED. |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 34, line 46 skipping to change at page 35, line 32
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-----------------------------------------------------+ +-----------------------------------------------------+
| Constraints for a METHOD:DECLINECOUNTER of a VEVENT | | Constraints for a METHOD:DECLINECOUNTER of a VEVENT |
+-----------------------------------------------------+ +-----------------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "DECLINECOUNTER" | | METHOD | 1 | MUST be DECLINECOUNTER. |
| | | | | | | |
| VEVENT | 1+ | All components MUST have the same | | VEVENT | 1+ | All components MUST have the same |
| | | UID | | | | UID. |
| ATTENDEE | 1+ | MUST for all attendees | | ATTENDEE | 1+ | MUST for all Attendees. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | MUST echo the original SEQUENCE | | SEQUENCE | 1 | MUST echo the original SEQUENCE |
| | | number | | | | number. |
| UID | 1 | MUST echo original UID | | UID | 1 | MUST echo original UID. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null | | DESCRIPTION | 0 or 1 | Can be null. |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| DTEND | 0 or 1 | if present DURATION MUST NOT be | | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | if present DTEND MUST NOT be | | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED | | STATUS | 0 or 1 | MAY be one of |
| SUMMARY | 0 or 1 | Can be null | | | | TENTATIVE/CONFIRMED. |
| SUMMARY | 0 or 1 | Can be null. |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VALARM | 0 | | | VALARM | 0 | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
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 applicable to the "VFREEBUSY" calendar component. Each of the
methods is defined using a restriction table. methods is 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.
The "FREEBUSY" property value MAY include a list of values, separated The "FREEBUSY" property value MAY include a list of values, separated
by the COMMA character (US-ASCII decimal 44). Alternately, multiple by the COMMA character (US-ASCII decimal 44). Alternately, multiple
busy time periods MAY be specified with multiple instances of the busy time periods MAY be specified with multiple instances of the
"FREEBUSY" property. Both forms MUST be supported by implementations "FREEBUSY" property. Both forms MUST be supported by implementations
conforming to this document. Duplicate busy time periods SHOULD NOT conforming to this document. Duplicate busy time periods SHOULD NOT
be specified in an iCalendar object. However, two different busy be specified in an iCalendar object. However, two different busy
time periods MAY overlap. time periods MAY overlap.
"FREEBUSY" properties SHOULD be sorted such that their values are in "FREEBUSY" properties SHOULD be sorted such that their values are in
ascending order, based on the start time, and then the end time, with ascending order, based on the start time and then the end time, with
the earliest periods first. For example, today's busy time the earliest periods first. For example, today's busy time
information should appear after yesterday's busy time information. information should appear after yesterday's busy time information.
And the busy time for this half-hour should appear after the busy And the busy time for this half-hour should appear after the busy
time for earlier today. Busy time periods can also span a day time for earlier today. Busy time periods can also span a day
boundary. boundary.
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.
+---------+-------------------------------------+ +---------+-------------------------------------+
skipping to change at page 37, line 16 skipping to change at page 38, line 14
The "ORGANIZER" property MUST be specified in the busy time The "ORGANIZER" property MUST be specified in the busy time
information. The value is the CU address of the originator of the information. The value is the CU address of the originator of the
busy time information. busy time information.
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, periodicity, such as a calendar week, month, or year. In this case,
each "VFREEBUSY" calendar component MUST include the "ORGANIZER", each "VFREEBUSY" calendar component MUST include the "ORGANIZER",
"DTSTART" and "DTEND" properties in order to specify the source of "DTSTART", 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. the busy time information covers.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-------------------------------------------------+ +-------------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VFREEBUSY | | Constraints for a METHOD:PUBLISH of a VFREEBUSY |
+-------------------------------------------------+ +-------------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "PUBLISH" | | METHOD | 1 | MUST be PUBLISH. |
| | | | | | | |
| VFREEBUSY | 1+ | | | VFREEBUSY | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | DateTime values must be in UTC | | DTSTART | 1 | DateTime values must be in UTC. |
| DTEND | 1 | DateTime values must be in UTC | | DTEND | 1 | DateTime values must be in UTC. |
| FREEBUSY | 0+ | MUST be BUSYTIME. Multiple | | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
| | | instances are allowed. Multiple | | | | instances are allowed. Multiple |
| | | instances SHOULD be sorted in | | | | instances SHOULD be sorted in |
| | | ascending order | | | | ascending order. |
| ORGANIZER | 1 | MUST contain the address of | | ORGANIZER | 1 | MUST contain the address of |
| | | originator of busy time data. | | | | originator of busy time data. |
| UID | 1 | | | UID | 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0 or 1 | | | CONTACT | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| URL | 0 or 1 | Specifies busy time URL | | URL | 0 or 1 | Specifies busy time URL. |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| DURATION | 0 | | | DURATION | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
skipping to change at page 39, line 4 skipping to change at page 40, line 14
3.3.2. REQUEST 3.3.2. REQUEST
The "REQUEST" method in a "VFREEBUSY" calendar component is used to The "REQUEST" method in a "VFREEBUSY" calendar component is used to
ask a "Calendar User" for their busy time information. The request ask a "Calendar User" for their busy time information. The request
may be for a busy time information bounded by a specific date and may be for a busy time information bounded by a specific date and
time interval. time 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 of 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 busy time request on the recipient's calendar system, then an
exception message SHOULD be returned in a "REPLY" method, but no busy exception message SHOULD be returned in a "REPLY" method, but no busy
time data need be returned. time data need be returned.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-------------------------------------------------+ +-------------------------------------------------+
| Constraints for a METHOD:REQUEST of a VFREEBUSY | | Constraints for a METHOD:REQUEST of a VFREEBUSY |
+-------------------------------------------------+ +-------------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REQUEST" | | METHOD | 1 | MUST be REQUEST. |
| | | | | | | |
| VFREEBUSY | 1 | | | VFREEBUSY | 1 | |
| ATTENDEE | 1+ | contains the calendar user | | ATTENDEE | 1+ | Contains the calendar user |
| | | addresses of the calendar users | | | | addresses of the "Calendar Users" |
| | | whose freebusy is being requested | | | | whose freebusy is being |
| DTEND | 1 | DateTime values must be in UTC | | | | requested. |
| DTEND | 1 | DateTime values must be in UTC. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | DateTime values must be in UTC | | DTSTART | 1 | DateTime values must be in UTC. |
| ORGANIZER | 1 | MUST be the request originator's | | ORGANIZER | 1 | MUST be the request originator's |
| | | address | | | | address. |
| UID | 1 | | | UID | 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0 or 1 | | | CONTACT | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| FREEBUSY | 0 | | | FREEBUSY | 0 | |
| DURATION | 0 | | | DURATION | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| URL | 0 | | | URL | 0 | |
| | | | | | | |
skipping to change at page 41, line 8 skipping to change at page 43, line 12
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-----------------------------------------------+ +-----------------------------------------------+
| Constraints for a METHOD:REPLY of a VFREEBUSY | | Constraints for a METHOD:REPLY of a VFREEBUSY |
+-----------------------------------------------+ +-----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REPLY" | | METHOD | 1 | MUST be REPLY. |
| | | | | | | |
| VFREEBUSY | 1 | | | VFREEBUSY | 1 | |
| ATTENDEE | 1 | MUST be the address of the | | ATTENDEE | 1 | MUST be the address of the |
| | | Attendee replying. | | | | Attendee replying. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTEND | 1 | DateTime values must be in UTC | | DTEND | 1 | DateTime values must be in UTC. |
| DTSTART | 1 | DateTime values must be in UTC | | DTSTART | 1 | DateTime values must be in UTC. |
| FREEBUSY | 0+ | MUST be BUSYTIME. Multiple | | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
| | | instances are allowed. Multiple | | | | instances are allowed. Multiple |
| | | instances SHOULD be sorted in | | | | instances SHOULD be sorted in |
| | | ascending order | | | | ascending order. |
| ORGANIZER | 1 | MUST be the request originator's | | ORGANIZER | 1 | MUST be the request originator's |
| | | address | | | | address. |
| UID | 1 | MUST be the UID of the original | | UID | 1 | MUST be the UID of the original |
| | | REQUEST | | | | REQUEST. |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0 or 1 | | | CONTACT | 0 or 1 | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| URL | 0 or 1 | specifies busy time URL | | URL | 0 or 1 | Specifies busy time URL. |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| DURATION | 0 | | | DURATION | 0 | |
| SEQUENCE | 0 | | | SEQUENCE | 0 | |
| | | | | | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTIMEZONE | 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 page 42, line 43 skipping to change at page 44, line 50
| | | | | |
| 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. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
3.4.1. PUBLISH 3.4.1. PUBLISH
The "PUBLISH" method in a "VTODO" calendar component has no The "PUBLISH" method in a "VTODO" calendar component has no
associated response. It is simply a posting of an iCalendar object associated response. It is simply a posting of an iCalendar object
that maybe added to a calendar. It MUST have an "Organizer". It that may be added to a calendar. It MUST have an "Organizer". It
MUST NOT have "Attendees". Its expected usage is for encapsulating MUST NOT have "Attendees". Its expected usage is for encapsulating
an arbitrary "VTODO" calendar component as an iCalendar object. The an arbitrary "VTODO" calendar component as an iCalendar object. The
"Organizer" MAY subsequently update (with another "PUBLISH" method), "Organizer" MAY subsequently update (with another "PUBLISH" method),
add instances to (with an "ADD" method), or cancel (with a "CANCEL" add instances to (with an "ADD" method), or cancel (with a "CANCEL"
method) a previously published "VTODO" calendar component. method) a previously published "VTODO" calendar component.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+---------------------------------------------+ +---------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VTODO | | Constraints for a METHOD:PUBLISH of a VTODO |
+---------------------------------------------+ +---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "PUBLISH" | | METHOD | 1 | MUST be PUBLISH. |
| | | | | | | |
| VTODO | 1+ | | | VTODO | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| PRIORITY | 1 | | | PRIORITY | 1 | |
| SEQUENCE | 0 or 1 | MUST be present if value is | | SEQUENCE | 0 or 1 | MUST be present if value is |
| | | greater than 0, MAY be present if | | | | greater than 0; MAY be present if |
| | | 0 | | | | 0. |
| SUMMARY | 1 | Can be null. | | SUMMARY | 1 | Can be null. |
| UID | 1 | | | UID | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| COMPLETED | 0 or 1 | | | COMPLETED | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null | | DESCRIPTION | 0 or 1 | Can be null. |
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present, DUE MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | COMPLETED/NEEDS-ACTION/ | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS/CANCELLED | | | | IN-PROCESS/CANCELLED. |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VJOURNAL | 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:
o Assign a to-do to one or more "Calendar Users" o Assign a to-do to one or more "Calendar Users".
o Reschedule an existing to-do
o Update the details of an existing to-do, without rescheduling it o Reschedule an existing to-do.
o Update the details of an existing to-do, without rescheduling it.
o Update the completion status of "Attendees" of an existing to-do, o Update the completion status of "Attendees" of an existing to-do,
without rescheduling it without rescheduling it.
o Reconfirm an existing to-do, without rescheduling it
o Delegate/reassign an existing to-do to another "Calendar User" o Reconfirm an existing to-do, without rescheduling it.
o 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 component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property
value sequences. value sequences.
Typically the originator of a "REQUEST" is the "Organizer" of the Typically, the originator of a "REQUEST" is the "Organizer" of the
to-do, and the recipient of a "REQUEST" is the "Calendar User" to-do, and the recipient of a "REQUEST" is the "Calendar User"
assigned the to-do. The "Attendee" uses the "REPLY" method to convey assigned the to-do. The "Attendee" uses the "REPLY" method to convey
their acceptance and completion status to the "Organizer" of the their acceptance and completion status to the "Organizer" of the
"REQUEST". "REQUEST".
The "UID", "SEQUENCE", and "DTSTAMP" properties are used to The "UID", "SEQUENCE", and "DTSTAMP" properties are used to
distinguish the various uses of the "REQUEST" method. If the "UID" distinguish the various uses of the "REQUEST" method. If the "UID"
property value in the "REQUEST" is not found on the recipient's property value in the "REQUEST" is not found on the recipient's
calendar, then the "REQUEST" is for a new to-do. If the "UID" calendar, then the "REQUEST" is for a new to-do. If the "UID"
property value is found on the recipient's calendar, then the property value is found on the recipient's calendar, then the
"REQUEST" is a rescheduling, an update, or a reconfirm of the "VTODO" "REQUEST" is a rescheduling, an update, or a reconfirmation of the
calendar object. "VTODO" calendar object.
If the "Organizer" of the "REQUEST" method is not authorized to make If the "Organizer" of the "REQUEST" method is not authorized to make
a to-do request on the "Attendee's" calendar system, then an a to-do request on the "Attendee's" calendar system, then an
exception is returned in the "REQUEST-STATUS" property of a exception is returned in the "REQUEST-STATUS" property of a
subsequent "REPLY" method, but no scheduling action is performed. subsequent "REPLY" method, but no scheduling action is performed.
For the "REQUEST" method, multiple "VTODO" components in a single For the "REQUEST" method, multiple "VTODO" components in a single
iCalendar object are only permitted when for components with the same iCalendar object are only permitted for components with the same
"UID" property. That is, a series of recurring events may have "UID" property. That is, a series of recurring events may have
instance-specific information. In this case, multiple "VTODO" instance-specific information. In this case, multiple "VTODO"
components are needed to express the entire series. components are needed to express the entire series.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+---------------------------------------------+ +---------------------------------------------+
| Constraints for a METHOD:REQUEST of a VTODO | | Constraints for a METHOD:REQUEST of a VTODO |
+---------------------------------------------+ +---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REQUEST" | | METHOD | 1 | MUST be REQUEST. |
| | | | | | | |
| VTODO | 1+ | All components must have the same | | VTODO | 1+ | All components must have the same |
| | | UID | | | | UID. |
| ATTENDEE | 1+ | | | ATTENDEE | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| PRIORITY | 1 | | | PRIORITY | 1 | |
| SEQUENCE | 0 or 1 | MUST be present if value is | | SEQUENCE | 0 or 1 | MUST be present if value is |
| | | greater than 0, MAY be present if | | | | greater than 0; MAY be present if |
| | | 0 | | | | 0. |
| SUMMARY | 1 | Can be null | | SUMMARY | 1 | Can be null. |
| UID | 1 | | | UID | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| COMPLETED | 0 or 1 | | | COMPLETED | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null | | DESCRIPTION | 0 or 1 | Can be null |
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present, DUE MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | COMPLETED/NEEDS-ACTION/ | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS | | | | IN-PROCESS. |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 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 existing "VTODO" calendar component in terms of its start or due
or recurrence intervals and possibly the description. If the time, recurrence intervals, and possibly the description. If the
recipient CUA of a "REQUEST" method finds that the "UID" property recipient CUA of a "REQUEST" method finds that the "UID" property
value already exists on the calendar, but that the "SEQUENCE" value already exists on the calendar but that the "SEQUENCE" property
property value in the "REQUEST" is greater than the value for the value in the "REQUEST" is greater than the value for the existing
existing VTODO, then the "REQUEST" method describes a rescheduling of "VTODO", then the "REQUEST" method describes a rescheduling of the
the "VTODO" calendar component. "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
changes to the start or due time or recurrence intervals, nor changes to the start or due time, recurrence intervals, or
generally to the description for the "VTODO" calendar component. If (generally) the description for the "VTODO" calendar component. If
the recipient CUA of a "REQUEST" method finds that the "UID" property the recipient CUA of a "REQUEST" method finds that the "UID" property
value already exists on the calendar and that the "SEQUENCE" property value already exists on the calendar and that the "SEQUENCE" property
value in the "REQUEST" is the same as the value for the existing value in the "REQUEST" is the same as the value for the existing
event, then the "REQUEST" method describes an update of the "VTODO" event, then the "REQUEST" method describes an update of the "VTODO"
calendar component details, but not a rescheduling of the "VTODO" calendar component details, but not a rescheduling of the "VTODO"
calendar component. calendar component.
The update "REQUEST" is the appropriate response to a "REFRESH" The update "REQUEST" is the appropriate response to a "REFRESH"
method sent from an "Attendee" to the "Organizer" of a "VTODO" method sent from an "Attendee" to the "Organizer" of a "VTODO"
calendar component. calendar component.
skipping to change at page 47, line 38 skipping to change at page 49, line 49
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 "VTODO" calendar component. The unsolicited "REQUEST" methods are
used to update the details of the "VTODO" (without rescheduling it or used to update the details of the "VTODO" (without rescheduling it or
updating the completion status of "Attendees") or the "VTODO" updating the completion status of "Attendees") or the "VTODO"
calendar component itself (i.e., reconfirm the "VTODO"). calendar component itself (i.e., reconfirm the "VTODO").
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 The "REQUEST" method is also used to delegate or reassign ownership
of a "VTODO" calendar component to another "Calendar User". For of a "VTODO" calendar component to another "Calendar User". For
example, it may be used to delegate an "Attendee's" role (i.e. example, it may be used to delegate an "Attendee's" role (i.e.,
"chair", or "participant") for a "VTODO" calendar component. The "chair" or "participant") for a "VTODO" calendar component. The
"REQUEST" method is sent by one of the "Attendees" of an existing "REQUEST" method is sent by one of the "Attendees" of an existing
"VTODO" calendar component to some other individual. "VTODO" calendar component to some other individual.
For the purposes of this description, the "Attendee" delegating the For the purposes of this description, the "Attendee" delegating the
"VTODO" calendar component is referred to as the "Delegator". The "VTODO" calendar component is referred to as the "Delegator". The
"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
skipping to change at page 48, line 4 skipping to change at page 50, line 14
For the purposes of this description, the "Attendee" delegating the For the purposes of this description, the "Attendee" delegating the
"VTODO" calendar component is referred to as the "Delegator". The "VTODO" calendar component is referred to as the "Delegator". The
"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 "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 the calendar address of the "Delegate". The "Delegator" MUST also
send a "REPLY" method back to the "Organizer" with the "Delegator's" send a "REPLY" method back to the "Organizer" with the "Delegator's"
"Attendee" property "PARTSTAT" parameter value set to "DELEGATED". "Attendee" property "PARTSTAT" parameter value set to "DELEGATED".
In addition, the "DELEGATED-TO" parameter MUST be included with the In addition, the "DELEGATED-TO" parameter MUST be included with the
calendar address of the "Delegate". A response to the delegation calendar address of the "Delegate". A response to the delegation
"REQUEST" is sent from the "Delegate" to the "Organizer" and "REQUEST" is sent from the "Delegate" to the "Organizer", and
optionally, to the "Delegator". The "REPLY" method from the optionally to the "Delegator". The "REPLY" method from the
"Delegate" SHOULD include the "ATTENDEE" property with their calendar "Delegate" SHOULD include the "ATTENDEE" property with their calendar
address and the "DELEGATED-FROM" parameter with the value of the address and the "DELEGATED-FROM" parameter with the value of the
"Delegator's" calendar address. "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 parameter associated with the "Delegator's" "Attendee"
property to that of the "Delegate's" "ATTENDEE" property. For property to that of the "Delegate's" "ATTENDEE" property. For
example if the "Delegator's" "ATTENDEE" property specifies example, if the "Delegator's" "ATTENDEE" property specifies
"RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify "RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify
"RSVP=TRUE". "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 send the An "Attendee" assigned a "VTODO" calendar component may send the
"VTODO" calendar component to another new CU, not previously "VTODO" calendar component to another new CU not previously
associated with the "VTODO" calendar component. The current associated with the "VTODO" calendar component. The current
"Attendee" assigned the "VTODO" calendar component does this by "Attendee" assigned the "VTODO" calendar component does this by
forwarding the original "REQUEST" method to the new CU. The new CU forwarding the original "REQUEST" method to the new CU. The new CU
can send a "REPLY" to the "Organizer" of the "VTODO" calendar can send a "REPLY" to the "Organizer" of the "VTODO" calendar
component. The reply contains an "ATTENDEE" property for the new CU. component. The reply contains an "ATTENDEE" property for the new CU.
The "Organizer" ultimately decides whether or not the new CU becomes 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" 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 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 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 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- "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" do. If the "Organizer" decides to add the new CU, the new "ATTENDEE"
property is added to the "VTODO" calendar component. Furthermore, property is added to the "VTODO" calendar component. Furthermore,
the "Organizer" is free to change any "ATTENDEE" property parameter the "Organizer" is free to change any "ATTENDEE" property parameter
from the values supplied by the new CU to something the "Organizer" from the values supplied by the new CU to something the "Organizer"
considers appropriate. The "Organizer" SHOULD send the new attendee considers appropriate. The "Organizer" SHOULD send the new
a "REQUEST" message to inform them that they have been added. "Attendee" a "REQUEST" message to inform them that they have been
added.
When forwarding a "REQUEST" to another CU, the forwarding "Attendee" When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
MUST NOT make changes to the original message. MUST NOT make changes to the original message.
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
skipping to change at page 49, line 36 skipping to change at page 51, line 42
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
"VTODO" calendar component "REQUEST" method. Depending on the "VTODO" calendar component "REQUEST" method. Depending on the
"REQUEST-STATUS" value, no scheduling action may have been performed. "REQUEST-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 example, a "REPLY" method MAY be received from a "Delegate" of a
"VTODO" calendar component. In addition, the "REPLY" method MAY be "VTODO" calendar component. In addition, the "REPLY" method MAY be
received from an unknown "Calendar User", having been forwarded the received from an unknown "Calendar User" who has been forwarded the
"REQUEST" by an original "Attendee" of the "VTODO" calendar "REQUEST" by an original "Attendee" of the "VTODO" calendar
component. This uninvited "Attendee" MAY be accepted, or the component. This uninvited "Attendee" MAY be accepted or the
"Organizer" MAY cancel the "VTODO" calendar component for the "Organizer" MAY cancel the "VTODO" calendar component for the
uninvited "Attendee" by sending them a "CANCEL" method. uninvited "Attendee" by sending them a "CANCEL" method.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-------------------------------------------+ +-------------------------------------------+
| Constraints for a METHOD:REPLY of a VTODO | | Constraints for a METHOD:REPLY of a VTODO |
+-------------------------------------------+ +-------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REPLY" | | METHOD | 1 | MUST be REPLY. |
| | | | | | | |
| VTODO | 1+ | All component MUST have the same | | VTODO | 1+ | All components MUST have the same |
| | | UID | | | | UID. |
| ATTENDEE | 1 | MUST be the address of the | | ATTENDEE | 1 | MUST be the address of the |
| | | Attendee replying. | | | | Attendee replying. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| UID | 1 | MUST be the UID of the original | | UID | 1 | MUST be the UID of the original |
| | | REQUEST | | | | REQUEST. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| COMPLETED | 0 or 1 | | | COMPLETED | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present, DUE MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| SEQUENCE | 0 or 1 | MUST be the sequence number of | | SEQUENCE | 0 or 1 | MUST be the sequence number of |
| | | the original REQUEST if greater | | | | the original REQUEST if greater |
| | | than 0. MAY be present if 0. | | | | than 0. MAY be present if 0. |
| STATUS | 0 or 1 | | | STATUS | 0 or 1 | |
| SUMMARY | 0 or 1 | Can be null | | SUMMARY | 0 or 1 | Can be null. |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4.4. ADD 3.4.4. ADD
The "ADD" method allows the "Organizer" to add one or more new The "ADD" method allows the "Organizer" to add one or more new
instances to an existing "VTODO" using a single iTIP message without instances to an existing "VTODO" using a single iTIP message without
having to send the entire "VTODO" with all the existing instance having to send the entire "VTODO" with all the existing instance
data, as it would have to do if the "REQUEST" method were used. data, as it would have to do if the "REQUEST" method were used.
The "UID" must be that of the existing to-do. If the "UID" property The "UID" must be that of the existing to-do. If the "UID" property
value in the "ADD" is not found on the recipient's calendar, then the value in the "ADD" is not found on the recipient's calendar, then the
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 "VTODO". If an "Attendee" updated with the latest version of the "VTODO". If an "Attendee"
implementation does not support the "ADD" method it should respond implementation does not support the "ADD" method, it should respond
with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
When handling an "ADD" message, the "Attendee" treats each component When handling an "ADD" message, the "Attendee" treats each component
in the "ADD" message as if it were referenced via an "RDATE"in the in the "ADD" message as if it were referenced via an "RDATE" in the
main component. main component.
The "SEQUENCE" property value is incremented as the sequence of to- The "SEQUENCE" property value is incremented since the sequence of
dos has changed. to-dos has changed.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-----------------------------------------+ +-----------------------------------------+
| Constraints for a METHOD:ADD of a VTODO | | Constraints for a METHOD:ADD of a VTODO |
+-----------------------------------------+ +-----------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "ADD" | | METHOD | 1 | MUST be ADD. |
| | | | | | | |
| VTODO | 1 | | | VTODO | 1 | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| PRIORITY | 1 | | | PRIORITY | 1 | |
| SEQUENCE | 1 | MUST be greater than 0 | | SEQUENCE | 1 | MUST be greater than 0. |
| SUMMARY | 1 | Can be null | | SUMMARY | 1 | Can be null. |
| UID | 1 | MUST match that of the original | | UID | 1 | MUST match that of the original |
| | | to-do | | | | to-do. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| ATTENDEE | 0+ | | | ATTENDEE | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| COMPLETED | 0 or 1 | | | COMPLETED | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null | | DESCRIPTION | 0 or 1 | Can be null. |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present, DUE MUST NOT be |
| | | present | | | | present. |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | COMPLETED/NEEDS-ACTION/ | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS | | | | IN-PROCESS. |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| EXDATE | 0 | | | EXDATE | 0 | |
| RECURRENCE-ID | 0 | | | RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| RDATE | 0 | | | RDATE | 0 | |
| RRULE | 0 | | | RRULE | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 53, line 26 skipping to change at page 55, line 39
recurring "VTODO" calendar component, the "UID" property value for recurring "VTODO" calendar component, the "UID" property value for
the "VTODO" calendar component MUST be specified and a "RECURRENCE- the "VTODO" calendar component MUST be specified and a "RECURRENCE-
ID" MUST NOT be specified in the "CANCEL" method. In order to cancel ID" MUST NOT be specified in the "CANCEL" method. In order to cancel
an individual instance of a recurring "VTODO" calendar component, the an individual instance of a recurring "VTODO" calendar component, the
"RECURRENCE-ID" property value for the "VTODO" calendar component "RECURRENCE-ID" property value for the "VTODO" calendar component
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 "VTODO" calendar component: recurring "VTODO" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST a. The "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
"THISANDFUTURE" to indicate cancellation of the specified "VTODO" "THISANDFUTURE" to indicate cancellation of the specified "VTODO"
calendar component and all instances after calendar component and all instances after.
b. individual recurrence instances may be cancelled by specifying
multiple "VTODO" components with a "RECURRENCE-ID" property b. Individual recurrence instances may be cancelled by specifying
corresponding to one of the instances to be cancelled multiple "VTODO" components each with a "RECURRENCE-ID" property
corresponding to one of the instances to be cancelled.
The "Organizer" MUST send a "CANCEL" message to each "Attendee" The "Organizer" MUST send a "CANCEL" message to each "Attendee"
affected by the cancellation. This can be done using a single affected by the cancellation. This can be done by using either a
"CANCEL" message for all "Attendees", or multiple messages with single "CANCEL" message for all "Attendees" or multiple messages with
different subsets of the affected "Attendees" in each. different subsets of the affected "Attendees" in each.
When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
incremented as described in Section 2.1.4. incremented as described in Section 2.1.4.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+--------------------------------------------+ +--------------------------------------------+
| Constraints for a METHOD:CANCEL of a VTODO | | Constraints for a METHOD:CANCEL of a VTODO |
+--------------------------------------------+ +--------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "CANCEL" | | METHOD | 1 | MUST be CANCEL. |
| | | | | | | |
| VTODO | 1+ | | | VTODO | 1+ | |
| ATTENDEE | 0+ | MUST include some or all | | ATTENDEE | 0+ | MUST include some or all |
| | | "Attendees" being removed from | | | | Attendees being removed from the |
| | | the to-do. MUST include some or | | | | to-do. MUST include some or all |
| | | all "Attendees" if the entire | | | | Attendees if the entire to-do is |
| | | to-do is cancelled. | | | | cancelled. |
| UID | 1 | MUST echo original UID | | UID | 1 | MUST echo original UID. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | | | SEQUENCE | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| COMPLETED | 0 or 1 | | | COMPLETED | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present, DUE MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| STATUS | 0 or 1 | MUST be set to CANCELLED to | | STATUS | 0 or 1 | MUST be set to CANCELLED to |
| | | cancel the entire VTODO. If | | | | cancel the entire VTODO. If |
| | | removing specific "Attendees" | | | | removing specific Attendees, then |
| | | then MUST NOT be included. | | | | MUST NOT be included. |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4.6. REFRESH 3.4.6. REFRESH
skipping to change at page 55, line 34 skipping to change at page 57, line 48
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 A refresh of a recurrence instance of a "VTODO" calendar component
may be requested by specifying the "RECURRENCE-ID" property may be requested by specifying the "RECURRENCE-ID" property
corresponding to the associated "VTODO" calendar component. The corresponding to the associated "VTODO" calendar component. The
"Organizer" responds with the latest description and rendition of the "Organizer" responds with the latest description and rendition of the
"VTODO" calendar component. In most cases this will be a REQUEST "VTODO" calendar component. In most cases, this will be a "REQUEST"
unless the "VTODO" has been cancelled, in which case the ORGANIZER unless the "VTODO" has been cancelled, in which case the "Organizer"
MUST send a "CANCEL". This method is intended to facilitate machine MUST send a "CANCEL". This method is intended to facilitate machine
processing of requests for updates to a "VTODO" calendar component. processing of requests for updates to a "VTODO" calendar component.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+---------------------------------------------+ +---------------------------------------------+
| Constraints for a METHOD:REFRESH of a VTODO | | Constraints for a METHOD:REFRESH of a VTODO |
+---------------------------------------------+ +---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REFRESH" | | METHOD | 1 | MUST be REFRESH. |
| | | | | | | |
| VTODO | 1 | | | VTODO | 1 | |
| ATTENDEE | 1 | | | ATTENDEE | 1 | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| UID | 1 | MUST echo original UID | | UID | 1 | MUST echo original UID. |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTACH | 0 | | | ATTACH | 0 | |
| CATEGORIES | 0 | | | CATEGORIES | 0 | |
| CLASS | 0 | | | CLASS | 0 | |
| COMMENT | 0 | | | COMMENT | 0 | |
| COMPLETED | 0 | | | COMPLETED | 0 | |
| CONTACT | 0 | | | CONTACT | 0 | |
| CREATED | 0 | | | CREATED | 0 | |
| DESCRIPTION | 0 | | | DESCRIPTION | 0 | |
skipping to change at page 57, line 12 skipping to change at page 59, line 24
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
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. "Organizer" a counter proposal for the "VTODO" calendar 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 calendar component that provides the complete description of the
alternate "VTODO" calendar component. alternate "VTODO" calendar component.
The "Organizer" rejects the counter proposal by sending the The "Organizer" rejects the counter proposal by sending the
"Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
counter proposal by rescheduling the to-do as described in section counter proposal by rescheduling the to-do as described in
3.4.2.1 Rescheduling a To-Do. The "Organizers" CUA SHOULD send a Section 3.4.2.1, "REQUEST for Rescheduling a To-Do". The
"REQUEST" message to all "Attendees" affected by any change triggered "Organizer's" CUA SHOULD send a "REQUEST" message to all "Attendees"
by an accepted "COUNTER". affected by any change triggered by an accepted "COUNTER".
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+---------------------------------------------+ +---------------------------------------------+
| Constraints for a METHOD:COUNTER of a VTODO | | Constraints for a METHOD:COUNTER of a VTODO |
+---------------------------------------------+ +---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "COUNTER" | | METHOD | 1 | MUST be COUNTER. |
| | | | | | | |
| VTODO | 1 | | | VTODO | 1 | |
| ATTENDEE | 1+ | | | ATTENDEE | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| PRIORITY | 1 | | | PRIORITY | 1 | |
| SUMMARY | 1 | Can be null | | SUMMARY | 1 | Can be null. |
| UID | 1 | | | UID | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| COMPLETED | 0 or 1 | | | COMPLETED | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null | | DESCRIPTION | 0 or 1 | Can be null. |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present, DUE MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE | | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE |
| | | number. MUST be present if | | | | number. MUST be present if |
| | | non-zero. MAY be present if | | | | non-zero. MAY be present if |
| | | zero. | | | | zero. |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | COMPLETED/NEEDS-ACTION/ | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS/CANCELLED | | | | IN-PROCESS/CANCELLED. |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4.8. DECLINECOUNTER 3.4.8. DECLINECOUNTER
The "DECLINECOUNTER" method in a "VTODO" calendar component is used The "DECLINECOUNTER" method in a "VTODO" calendar component is used
by an "Organizer" of "VTODO" calendar component to reject a counter by an "Organizer" of the "VTODO" calendar component to reject a
proposal offered by one of the "Attendees". The "Organizer" sends counter proposal offered by one of the "Attendees". The "Organizer"
the message to the "Attendee" that sent the "COUNTER" method to the sends the message to the "Attendee" that sent the "COUNTER" method to
"Organizer". the "Organizer".
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+----------------------------------------------------+ +----------------------------------------------------+
| Constraints for a METHOD:DECLINECOUNTER of a VTODO | | Constraints for a METHOD:DECLINECOUNTER of a VTODO |
+----------------------------------------------------+ +----------------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "DECLINECOUNTER" | | METHOD | 1 | MUST be DECLINECOUNTER. |
| | | | | | | |
| VTODO | 1 | | | VTODO | 1 | |
| ATTENDEE | 1+ | MUST for all attendees | | ATTENDEE | 1+ | MUST for all ATTENDEEs. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | MUST echo the original SEQUENCE | | SEQUENCE | 1 | MUST echo the original SEQUENCE |
| | | number | | | | number. |
| UID | 1 | MUST echo original UID | | UID | 1 | MUST echo original UID. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| COMPLETED | 0 or 1 | | | COMPLETED | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present, DURATION MUST NOT be |
| | | present | | | | present. |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present, DUE MUST NOT be |
| | | present | | | | present. |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | COMPLETED/NEEDS-ACTION/ | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS | | | | IN-PROCESS. |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
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 The following summarizes the methods that are defined for the
"VJOURNAL" calendar component. "VJOURNAL" calendar component.
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| Method | Description | | Method | Description |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
skipping to change at page 62, line 8 skipping to change at page 63, line 37
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+------------------------------------------------+ +------------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VJOURNAL | | Constraints for a METHOD:PUBLISH of a VJOURNAL |
+------------------------------------------------+ +------------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "PUBLISH" | | METHOD | 1 | MUST be PUBLISH. |
| | | | | | | |
| VJOURNAL | 1+ | | | VJOURNAL | 1+ | |
| DESCRIPTION | 1 | Can be null. | | DESCRIPTION | 1 | Can be null. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| UID | 1 | | | UID | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| SEQUENCE | 0 or 1 | MUST be present if non-zero. MAY | | SEQUENCE | 0 or 1 | MUST be present if non-zero. MAY |
| | | be present if zero. | | | | be present if zero. |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | DRAFT/FINAL/CANCELLED | | | | DRAFT/FINAL/CANCELLED. |
| SUMMARY | 0 or 1 | Can be null | | SUMMARY | 0 or 1 | Can be null. |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 63, line 21 skipping to change at page 64, line 50
instances to an existing "VJOURNAL" using a single iTIP message instances to an existing "VJOURNAL" using a single iTIP message
without having to send the entire "VJOURNAL" with all the existing without having to send the entire "VJOURNAL" with all the existing
instance data, as it would have to do if the "REQUEST" method were instance data, as it would have to do if the "REQUEST" method were
used. used.
The "UID" must be that of the existing journal entry. If the "UID" The "UID" must be that of the existing journal entry. If the "UID"
property value in the "ADD" is not found on the recipient's calendar, property value in the "ADD" is not found on the recipient's calendar,
then the recipient MAY treat the "ADD" as a "PUBLISH". then the recipient MAY treat the "ADD" as a "PUBLISH".
When handling an "ADD" message, the "Attendee" treats each component When handling an "ADD" message, the "Attendee" treats each component
in the "ADD" message as if it were referenced via an "RDATE"in the in the "ADD" message as if it were referenced via an "RDATE" in the
main component. There is no response to the "Organizer". main component. There is no response to the "Organizer".
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+--------------------------------------------+ +--------------------------------------------+
| Constraints for a METHOD:ADD of a VJOURNAL | | Constraints for a METHOD:ADD of a VJOURNAL |
+--------------------------------------------+ +--------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "ADD" | | METHOD | 1 | MUST be ADD. |
| | | | | | | |
| VJOURNAL | 1 | | | VJOURNAL | 1 | |
| DESCRIPTION | 1 | Can be null | | DESCRIPTION | 1 | Can be null. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | MUST be greater than 0 | | SEQUENCE | 1 | MUST be greater than 0. |
| UID | 1 | MUST match that of the original | | UID | 1 | MUST match that of the original |
| | | journal | | | | journal. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | DRAFT/FINAL/CANCELLED | | | | DRAFT/FINAL/CANCELLED. |
| SUMMARY | 0 or 1 | Can be null | | SUMMARY | 0 or 1 | Can be null. |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| EXDATE | 0 | | | EXDATE | 0 | |
| RECURRENCE-ID | 0 | | | RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| RDATE | 0 | | | RDATE | 0 | |
| RRULE | 0 | | | RRULE | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 65, line 21 skipping to change at page 66, line 28
journal entry may be cancelled. To cancel the complete range of a journal entry may be cancelled. To cancel the complete range of a
recurring journal entry, the "UID" property value for the journal recurring journal entry, the "UID" property value for the journal
entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be
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 journal entry, the "RECURRENCE-ID" property value for instance of the journal entry, the "RECURRENCE-ID" property value for
the journal entry MUST be specified in the "CANCEL" method. the journal entry 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 "VJOURNAL" calendar component: recurring "VJOURNAL" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST a. The "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
"THISANDFUTURE" to indicate cancellation of the specified "VTODO" "THISANDFUTURE" to indicate cancellation of the specified
calendar component and all instances after "VJOURNAL" calendar component and all instances after.
b. individual recurrence instances may be cancelled by specifying
multiple "VJOURNAL" components with a "RECURRENCE-ID" property b. Individual recurrence instances may be cancelled by specifying
corresponding to one of the instances to be cancelled multiple "VJOURNAL" components each with a "RECURRENCE-ID"
property corresponding to one of the instances to be cancelled.
When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be
incremented as described in Section 2.1.4. incremented as described in Section 2.1.4.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-----------------------------------------------+ +-----------------------------------------------+
| Constraints for a METHOD:CANCEL of a VJOURNAL | | Constraints for a METHOD:CANCEL of a VJOURNAL |
+-----------------------------------------------+ +-----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "CANCEL" | | METHOD | 1 | MUST be CANCEL. |
| | | | | | | |
| VJOURNAL | 1+ | All MUST have the same UID | | VJOURNAL | 1+ | All MUST have the same UID. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | | | SEQUENCE | 1 | |
| UID | 1 | MUST be the UID of the original | | UID | 1 | MUST be the UID of the original |
| | | REQUEST | | | | REQUEST. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise, it MUST |
| | | be present. | | | | NOT be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be present, must be | | STATUS | 0 or 1 | MAY be present; MUST be CANCELLED |
| | | "CANCELLED" if present | | | | if present. |
| SUMMARY | 0 or 1 | | | SUMMARY | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone. |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.6. Status Replies 3.6. Status Replies
The "REQUEST-STATUS" property is used to convey status information The "REQUEST-STATUS" property is used to convey status information
about a REPLY, COUNTER or DECLINECOUNTER iTIP message. The codes about a "REPLY", "COUNTER", or "DECLINECOUNTER" iTIP message. The
listed in the table below SHOULD be used. If the "REQUEST-STATUS" codes listed in the table below SHOULD be used. If the "REQUEST-
property is not present in one of these iTIP messages, then a status STATUS" property is not present in one of these iTIP messages, then a
code of "2.0" (success) MUST be assumed. status code of "2.0" (success) MUST be assumed.
This specification adds a new IANA registry for REQUEST-STATUS This specification adds a new IANA registry for "REQUEST-STATUS"
values, as defined in Section 7, which includes a new registration property values, as defined in Section 7, which includes a new
template for defining the specific components of the REQUEST-STATUS registration template for defining the specific components of the
value. Additional codes MAY be used provided the process described "REQUEST-STATUS" property value. Additional codes MAY be used,
in Section 8.2.1 of [RFC5545] is used to register them. provided the process described in Section 8.2.1 of [RFC5545] is used
to register them.
This specification allows for multiple "REQUEST-STATUS" properties to This specification allows for multiple "REQUEST-STATUS" properties to
be returned in iCalendar components in the appropriate iTIP messages. be returned in iCalendar components in the appropriate iTIP messages.
When multiple "REQUEST-STATUS" properties are present, the following When multiple "REQUEST-STATUS" properties are present, the following
restrictions apply: restrictions apply:
1. Within any one component, the "top-level" numeric value of the 1. Within any one component, the "top-level" numeric value of the
"short return status code" MUST be the same for all REQUEST- "short return status code" MUST be the same for all "REQUEST-
STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx STATUS" properties, i.e., there cannot be a mixture of, e.g.,
and 5.xx codes within a single component. 2.xx and 5.xx codes within a single component.
2. Across all components in the iTIP message, the following applies: 2. Across all components in the iTIP message, the following applies:
A. If any one component would have a 5.xx code, then all
A. If any one component would have a 5.xx code, then either all
components MUST have a code in that range or "REQUEST-STATUS" components MUST have a code in that range or "REQUEST-STATUS"
MUST NOT be present in the other components if a 5.xx code is MUST NOT be present in the other components if a 5.xx code is
not appropriate for those components. not appropriate for those components.
B. Otherwise, if any one component would have a 3.xx code, then B. Otherwise, if any one component would have a 3.xx code, then
all components MUST have a code in that range or "REQUEST- either all components MUST have a code in that range or
STATUS" MUST NOT be present in the other components if a 3.xx "REQUEST-STATUS" MUST NOT be present in the other components
code is not appropriate for those components. if a 3.xx code is not appropriate for those components.
C. 2.xx and 4.xx codes can be used in different components
C. 2.xx and 4.xx codes can be used in different components,
provided that each component follows the restriction in (1) provided that each component follows the restriction in (1)
above. above.
The following "REQUEST-STATUS" codes are defined (any "Offending The following "REQUEST-STATUS" codes are defined (any "Offending
Data" MAY be specified in the "REQUEST-STATUS" value as the extdata Data" MAY be specified in the "REQUEST-STATUS" value as the extdata
field): field):
3.6.1. Status Code 2.0 3.6.1. Status Code 2.0
Status Code: 2.0 Status Code: 2.0
Status Description: Success. Status Description: Success.
Status Exception Data: None. Status Exception Data: None.
Description: iTIP operation succeeded. Description: iTIP operation succeeded.
3.6.2. Status Code 2.1 3.6.2. Status Code 2.1
Status Code: 2.1 Status Code: 2.1
Status Description: Success but fallback taken on one or more
Status Description: Success, but fallback taken on one or more
property values. property values.
Status Exception Data: Property name and value MAY be specified. Status Exception Data: Property name and value MAY be specified.
Description: iTIP operation succeeded with fallback on one or more Description: iTIP operation succeeded with fallback on one or more
property values. property values.
3.6.3. Status Code 2.2 3.6.3. Status Code 2.2
Status Code: 2.2 Status Code: 2.2
Status Description: Success, invalid property ignored.
Status Description: Success; invalid property ignored.
Status Exception Data: Property name MAY be specified. Status Exception Data: Property name MAY be specified.
Description: iTIP operation succeeded but a property was ignored. Description: iTIP operation succeeded but a property was ignored.
3.6.4. Status Code 2.3 3.6.4. Status Code 2.3
Status Code: 2.3 Status Code: 2.3
Status Description: Success, invalid property parameter ignored.
Status Description: Success; invalid property parameter ignored.
Status Exception Data: Property parameter name and value MAY be Status Exception Data: Property parameter name and value MAY be
specified. specified.
Description: iTIP operation succeeded but a property parameter was Description: iTIP operation succeeded but a property parameter was
ignored because it was invalid. ignored because it was invalid.
3.6.5. Status Code 2.4 3.6.5. Status Code 2.4
Status Code: 2.4 Status Code: 2.4
Status Description: Success, unknown non-standard property ignored.
Status Description: Success; unknown, non-standard property ignored.
Status Exception Data: Non-standard property name MAY be specified. Status Exception Data: Non-standard property name MAY be specified.
Description: iTIP operation succeeded but a property parameter was Description: iTIP operation succeeded but a property parameter was
ignored because it was unknown. ignored because it was unknown.
3.6.6. Status Code 2.5 3.6.6. Status Code 2.5
Status Code: 2.5 Status Code: 2.5
Status Description: Success, unknown non-standard property value
Status Description: Success; unknown, non-standard property value
ignored. ignored.
Status Exception Data: Property and non-standard value MAY be Status Exception Data: Property and non-standard value MAY be
specified. specified.
Description: iTIP operation succeeded but a property was ignored Description: iTIP operation succeeded but a property was ignored
because its value was unknown. because its value was unknown.
3.6.7. Status Code 2.6 3.6.7. Status Code 2.6
Status Code: 2.6 Status Code: 2.6
Status Description: Success, invalid calendar component ignored.
Status Description: Success; invalid calendar component ignored.
Status Exception Data: Calendar component sentinel (e.g., BEGIN: Status Exception Data: Calendar component sentinel (e.g., BEGIN:
ALARM) MAY be specified. ALARM) MAY be specified.
Description: iTIP operation succeeded but a component was ignored Description: iTIP operation succeeded but a component was ignored
because it was invalid. because it was invalid.
3.6.8. Status Code 2.7 3.6.8. Status Code 2.7
Status Code: 2.7 Status Code: 2.7
Status Description: Success, request forwarded to Calendar User.
Status Description: Success; request forwarded to Calendar User.
Status Exception Data: Original and forwarded calendar user Status Exception Data: Original and forwarded calendar user
addresses MAY be specified. addresses MAY be specified.
Description: iTIP operation succeeded, and the request was forwarded Description: iTIP operation succeeded, and the request was forwarded
to another calendar user. to another Calendar User.
3.6.9. Status Code 2.8 3.6.9. Status Code 2.8
Status Code: 2.8 Status Code: 2.8
Status Description: Success, repeating event ignored. Scheduled as
Status Description: Success; repeating event ignored. Scheduled as
a single component. a single component.
Status Exception Data: RRULE or RDATE property name and value MAY be Status Exception Data: RRULE or RDATE property name and value MAY be
specified. specified.
Description: iTIP operation succeeded, but a repeating event was
Description: iTIP operation succeeded but a repeating event was
truncated to a single instance. truncated to a single instance.
3.6.10. Status Code 2.9 3.6.10. Status Code 2.9
Status Code: 2.9 Status Code: 2.9
Status Description: Success, truncated end date time to date
Status Description: Success; truncated end date time to date
boundary. boundary.
Status Exception Data: DTEND property value MAY be specified. Status Exception Data: DTEND property value MAY be specified.
Description: iTIP operation succeeded, but the end time was
truncated to a date boundary. Description: iTIP operation succeeded but the end time was truncated
to a date boundary.
3.6.11. Status Code 2.10 3.6.11. Status Code 2.10
Status Code: 2.10 Status Code: 2.10
Status Description: Success, repeating VTODO ignored. Scheduled as
Status Description: Success; repeating VTODO ignored. Scheduled as
a single VTODO. a single VTODO.
Status Exception Data: RRULE or RDATE property name and value MAY be Status Exception Data: RRULE or RDATE property name and value MAY be
specified. specified.
Description: iTIP operation succeeded, but a repeating todo was
Description: iTIP operation succeeded but a repeating to-do was
truncated to a single instance. truncated to a single instance.
3.6.12. Status Code 2.11 3.6.12. Status Code 2.11
Status Code: 2.11 Status Code: 2.11
Status Description: Success, unbounded RRULE clipped at some finite
Status Description: Success; unbounded RRULE clipped at some finite
number of instances. number of instances.
Status Exception Data: RRULE property name and value MAY be Status Exception Data: RRULE property name and value MAY be
specified. Number of instances MAY also be specified. specified. Number of instances MAY also be specified.
Description: iTIP operation succeeded, but an unbounded repeating
Description: iTIP operation succeeded but an unbounded repeating
object was clipped to a finite number of instances. object was clipped to a finite number of instances.
3.6.13. Status Code 3.0 3.6.13. Status Code 3.0
Status Code: 3.0 Status Code: 3.0
Status Description: Invalid property name. Status Description: Invalid property name.
Status Exception Data: Property name MAY be specified. Status Exception Data: Property name MAY be specified.
Description: iTIP operation failed because of an invalid property Description: iTIP operation failed because of an invalid property
name. name.
3.6.14. Status Code 3.1 3.6.14. Status Code 3.1
Status Code: 3.1 Status Code: 3.1
Status Description: Invalid property value. Status Description: Invalid property value.
Status Exception Data: Property name and value MAY be specified. Status Exception Data: Property name and value MAY be specified.
Description: iTIP operation failed because of an invalid property Description: iTIP operation failed because of an invalid property
value. value.
3.6.15. Status Code 3.2 3.6.15. Status Code 3.2
Status Code: 3.2 Status Code: 3.2
Status Description: Invalid property parameter. Status Description: Invalid property parameter.
Status Exception Data: Property parameter name and value MAY be Status Exception Data: Property parameter name and value MAY be
specified. specified.
Description: iTIP operation failed because of an invalid property Description: iTIP operation failed because of an invalid property
parameter. parameter.
3.6.16. Status Code 3.3 3.6.16. Status Code 3.3
Status Code: 3.3 Status Code: 3.3
Status Description: Invalid property parameter value. Status Description: Invalid property parameter value.
Status Exception Data: Property parameter name and value MAY be Status Exception Data: Property parameter name and value MAY be
specified. specified.
Description: iTIP operation failed because of an invalid property Description: iTIP operation failed because of an invalid property
parameter value. parameter value.
3.6.17. Status Code 3.4 3.6.17. Status Code 3.4
Status Code: 3.4 Status Code: 3.4
Status Description: Invalid calendar component sequence. Status Description: Invalid calendar component sequence.
Status Exception Data: Calendar component sentinel MAY be specified Status Exception Data: Calendar component sentinel MAY be specified
(e.g., BEGIN:VTIMEZONE). (e.g., BEGIN:VTIMEZONE).
Description: iTIP operation failed because of an invalid component. Description: iTIP operation failed because of an invalid component.
3.6.18. Status Code 3.5 3.6.18. Status Code 3.5
Status Code: 3.5 Status Code: 3.5
Status Description: Invalid date or time. Status Description: Invalid date or time.
Status Exception Data: Date/time value(s) MAY be specified. Status Exception Data: Date/time value(s) MAY be specified.
Description: iTIP operation failed because of an invalid date or Description: iTIP operation failed because of an invalid date or
time property. time property.
3.6.19. Status Code 3.6 3.6.19. Status Code 3.6
Status Code: 3.6 Status Code: 3.6
Status Description: Invalid rule. Status Description: Invalid rule.
Status Exception Data: Rule value MAY be specified.
Status Exception Data: RRULE property value MAY be specified.
Description: iTIP operation failed because of an invalid rule Description: iTIP operation failed because of an invalid rule
property. property.
3.6.20. Status Code 3.7 3.6.20. Status Code 3.7
Status Code: 3.7 Status Code: 3.7
Status Description: Invalid Calendar User. Status Description: Invalid Calendar User.
Status Exception Data: Attendee property value MAY be specified.
Description: iTIP operation failed because of an invalid Attendee Status Exception Data: ATTENDEE property value MAY be specified.
Description: iTIP operation failed because of an invalid ATTENDEE
property. property.
3.6.21. Status Code 3.8 3.6.21. Status Code 3.8
Status Code: 3.8 Status Code: 3.8
Status Description: No authority. Status Description: No authority.
Status Exception Data: METHOD and Attendee property values MAY be
Status Exception Data: METHOD and ATTENDEE property values MAY be
specified. specified.
Description: iTIP operation failed because an Attendee does not have Description: iTIP operation failed because an Attendee does not have
suitable privileges for the operation. suitable privileges for the operation.
3.6.22. Status Code 3.9 3.6.22. Status Code 3.9
Status Code: 3.9 Status Code: 3.9
Status Description: Unsupported version. Status Description: Unsupported version.
Status Exception Data: VERSION property name and value MAY be Status Exception Data: VERSION property name and value MAY be
specified. specified.
Description: iTIP operation failed because the calendar data version Description: iTIP operation failed because the calendar data version
is not supported. is not supported.
3.6.23. Status Code 3.10 3.6.23. Status Code 3.10
Status Code: 3.10 Status Code: 3.10
Status Description: Request entity too large. Status Description: Request entity too large.
Status Exception Data: Request entity too large.
Status Exception Data: None.
Description: iTIP operation failed because the calendar data was too Description: iTIP operation failed because the calendar data was too
large. large.
3.6.24. Status Code 3.11 3.6.24. Status Code 3.11
Status Code: 3.11 Status Code: 3.11
Status Description: Required component or property missing. Status Description: Required component or property missing.
Status Exception Data: Component or property name MAY be specified. Status Exception Data: Component or property name MAY be specified.
Description: iTIP operation failed because the calendar data did not Description: iTIP operation failed because the calendar data did not
contain a required property or component. contain a required property or component.
3.6.25. Status Code 3.12 3.6.25. Status Code 3.12
Status Code: 3.12 Status Code: 3.12
Status Description: Unknown component or property found. Status Description: Unknown component or property found.
Status Exception Data: Component or property name MAY be specified. Status Exception Data: Component or property name MAY be specified.
Description: iTIP operation failed because the calendar data Description: iTIP operation failed because the calendar data
contained an unknown property or component. contained an unknown property or component.
3.6.26. Status Code 3.13 3.6.26. Status Code 3.13
Status Code: 3.13 Status Code: 3.13
Status Description: Unsupported component or property found. Status Description: Unsupported component or property found.
Status Exception Data: Component or property name MAY be specified. Status Exception Data: Component or property name MAY be specified.
Description: iTIP operation failed because the calendar data Description: iTIP operation failed because the calendar data
contained an unsupported property or component. contained an unsupported property or component.
3.6.27. Status Code 3.14 3.6.27. Status Code 3.14
Status Code: 3.14 Status Code: 3.14
Status Description: Unsupported capability. Status Description: Unsupported capability.
Status Exception Data: METHOD or action MAY be specified. Status Exception Data: METHOD or action MAY be specified.
Description: iTIP operation failed because the operation is not Description: iTIP operation failed because the operation is not
supported. supported.
3.6.28. Status Code 4.0 3.6.28. Status Code 4.0
Status Code: 4.0 Status Code: 4.0
Status Description: Event conflict. Date/time is busy. Status Description: Event conflict. Date/time is busy.
Status Exception Data: DTSTART and DTEND property name and values
Status Exception Data: DTSTART and DTEND property names and values
MAY be specified. MAY be specified.
Description: iTIP operation failed because the event overlaps the Description: iTIP operation failed because the event overlaps the
date and time of another event. date and time of another event.
3.6.29. Status Code 5.0 3.6.29. Status Code 5.0
Status Code: 5.0 Status Code: 5.0
Status Description: Request not supported. Status Description: Request not supported.
Status Exception Data: METHOD property value MAY be specified. Status Exception Data: METHOD property value MAY be specified.
Description: iTIP operation failed because the operation is not Description: iTIP operation failed because the operation is not
supported. supported.
3.6.30. Status Code 5.1 3.6.30. Status Code 5.1
Status Code: 5.1 Status Code: 5.1
Status Description: Service unavailable. Status Description: Service unavailable.
Status Exception Data: ATTENDEE property value MAY be specified. Status Exception Data: ATTENDEE property value MAY be specified.
Description: iTIP operation failed because scheduling is not active. Description: iTIP operation failed because scheduling is not active.
3.6.31. Status Code 5.2 3.6.31. Status Code 5.2
Status Code: 5.2 Status Code: 5.2
Status Description: Invalid calendar service. Status Description: Invalid calendar service.
Status Exception Data: ATTENDEE property value MAY be specified. Status Exception Data: ATTENDEE property value MAY be specified.
Description: iTIP operation failed because there is no scheduling Description: iTIP operation failed because there is no scheduling
capability. capability.
3.6.32. Status Code 5.3 3.6.32. Status Code 5.3
Status Code: 5.3 Status Code: 5.3
Status Description: No scheduling support for user. Status Description: No scheduling support for user.
Status Exception Data: ATTENDEE property value MAY be specified. Status Exception Data: ATTENDEE property value MAY be specified.
Description: iTIP operation failed because scheduling is not enabled Description: iTIP operation failed because scheduling is not enabled
for an Attendee. for an Attendee.
3.7. Implementation Considerations 3.7. Implementation Considerations
3.7.1. Working With Recurrence Instances 3.7.1. Working With Recurrence Instances
iCalendar includes a recurrence grammar to represent recurring iCalendar includes a recurrence grammar to represent recurring
events. The benefit of such a grammar is the ability to represent a events. The benefit of such a grammar is the ability to represent a
number of events in a single object. However, while this simplifies number of events in a single object. However, while this simplifies
skipping to change at page 74, line 28 skipping to change at page 77, line 39
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 discrete, related event single event object or a collection of discrete, related event
objects, the protocol is designed so that each recurring instance may objects, the protocol is designed so that each recurring instance may
be both referenced and versioned. Hence, implementations that choose be both referenced and versioned. Hence, implementations that choose
to maintain per-instance properties (such as "ATTENDEE" property to maintain per-instance properties (such as "ATTENDEE" property
"PARTSTAT" parameter) may do so. However, the protocol does not "PARTSTAT" parameter) may do so. However, the protocol does not
require per-instance recognition unless the instance itself must be require per-instance recognition unless the instance itself must be
renegotiated. renegotiated.
The scenarios for recurrence instance referencing are listed below. The scenarios for recurrence instance referencing are listed below.
For purposes of simplification a change to an event refers to a For purposes of simplification, a change to an event refers to a
"trigger property." That is, a property that has a substantive "trigger property." That is, a property that has a substantive
effect on the meeting itself such as start time, location, due date effect on the meeting itself, such as start time, location, due date
(for "VTODO" calendar component components) and possibly description. (for "VTODO" calendar components), and possibly description.
"Organizer" initiated actions: "Organizer"-initiated actions:
o "Organizer" deletes or changes a single instance of a recurring o deletes or changes a single instance of a recurring event
event
o "Organizer" makes changes that affect all future instances
o "Organizer" makes changes that affect all previous instances
o "Organizer" deletes or modifies a previously changed instance
"Attendee" initiated actions: o makes changes that affect all future instances
o "Attendee" changes status for a particular recurrence instance o makes changes that affect all previous instances
o "Attendee" sends event-Counter for a particular recurrence
instance o deletes or modifies a previously changed instance
"Attendee"-initiated actions:
o changes status for a particular recurrence instance
o sends a "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,
"RECURRENCE-ID" property, when that instance is renegotiated. "RECURRENCE-ID" property, when that instance is renegotiated.
Negotiation may be necessary when a substantive change to the event Negotiation may be necessary when a substantive change to the event
or to-do has been made (such as changing the start time, end time, or to-do has been made (such as changing the start time, end time,
due date or location). The "Organizer" can identify a specific due date, or location). The "Organizer" can identify a specific
recurrence instance using the "RECURRENCE-ID" property. The property recurrence instance using the "RECURRENCE-ID" property. The property
value is equal to the date/time of the instance. If the "Organizer" value is equal to the date/time of the instance. If the "Organizer"
wishes to change the "DTSTART", the original unmodified "DTSTART" wishes to change the "DTSTART", the original, unmodified "DTSTART"
value of the instance is used as the value "RECURRENCE-ID" property value of the instance is used as the value "RECURRENCE-ID" property,
and the new "DTSTART" and "DTEND" values reflect the change. and the new "DTSTART" and "DTEND" values reflect the change.
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 journal entries for two reasons. First, only the "Organizer" is
allowed to update and redistribute an event or to-do component. It allowed to update and redistribute an event or to-do component. It
follows that the "ORGANIZER" property MUST be present in the event, follows that the "ORGANIZER" property MUST be present in the event,
to-do, or journal entry component so that the CUA has a basis for to-do, or journal entry component so that the CUA has a basis for
authorizing an update. Second, it is prudent to provide a point of authorizing an update. Second, it is prudent to provide a point of
contact for anyone who receives a published component in case of contact for anyone who receives a published component, in case of
problems. problems.
Email addresses that correspond to groups of calendar users could be Email addresses that correspond to groups of "Calendar Users" could
specified as a mailto: URI [RFC2368] calendar user address. Sending be specified as a mailto: URI [RFC2368] calendar user address.
email to such an address results in email being sent to multiple Sending email to such an address results in email being sent to
recipients. Such an address may be used as the value of an multiple recipients. Such an address may be used as the value of an
"ATTENDEE" property. Thus, it is possible that the recipient of a "ATTENDEE" property. Thus, it is possible that the recipient of a
"REQUEST" does not appear explicitly in the list. "REQUEST" does not appear explicitly in the list.
It is recommended that the general approach to finding a "Calendar It is recommended that the general approach to finding a "Calendar
User" in an attendee list be as follows: User" 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
"CUTYPE=INDIVIDUAL" "CUTYPE=INDIVIDUAL"
2. Failing (1) look for attendees where "CUTYPE=GROUP" or
'CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User" 2. Failing (1), look for "Attendees" where "CUTYPE=GROUP" or
"CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User"
is a member of one of these groups. If so, the "REPLY" method is a member of one of these groups. If so, the "REPLY" method
sent to the "Organizer" MUST contain a new "ATTENDEE" property in sent to the "Organizer" MUST contain a new "ATTENDEE" property in
which: which:
3.
* the "TYPE" property parameter is set to INDIVIDUAL * the "TYPE" property parameter is set to INDIVIDUAL
* the "MEMBER" property parameter is set to the name of the * the "MEMBER" property parameter is set to the name of the
group group
4. 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 User" wishes. "Calendar User" wishes.
3.7.3. Extension Tokens 3.7.3. Extension Tokens
To make iCalendar objects extensible, new component, property or To make iCalendar objects extensible, new component, property, or
property parameters can be used. Two types of extension exist: IANA property parameters can be used. Two types of extensions are defined
registered tokens and X- vendor-specific tokens. A client SHOULD by [RFC5545]: IANA-registered tokens ("iana-token") and experimental
save IANA tokens and MAY use them in replies. A client MAY save X- use tokens ("x-name"). A client SHOULD save "iana-token's" and MAY
Tokens and MAY use them in replies. When delegating or forwarding use them in replies. A client MAY save "x-name's" and MAY use them
messages to other CUs, a client SHOULD include IANA and X- tokens. in replies. When delegating or forwarding messages to other CUs, a
client SHOULD include "iana-token's" and "x-names's".
4. Examples 4. Examples
4.1. Published Event Examples 4.1. Published Event Examples
In the calendaring and scheduling context, publication refers to the In the calendaring and scheduling context, publication refers to the
one way transfer of event information. Consumers of published events one-way transfer of event information. Consumers of published events
simply incorporate the event into a calendar. No reply is expected. simply incorporate the event into a calendar. No reply is expected.
Individual "A" publishes an event. Individual "B" reads the event Individual "A" publishes an event. Individual "B" reads the event
and incorporates it into their calendar. Events are published in and incorporates it into their calendar. Events are published in
several ways including: embedding the event as an object in a web several ways, including embedding the event as an object in a web
page, e-mailing the event to a distribution list, or posting the page, emailing the event to a distribution list, or posting the event
event to a newsgroup. to a newsgroup.
The table below illustrates the sequence of events between the The table below illustrates the sequence of events between the
publisher and the consumers of a published event. publisher and the consumers of a published event.
+-----------------+-----------------------+-------------------------+ +----------------+-----------------------+--------------------------+
| Action | Organizer | Receiver | | Action | Organizer | Receiver |
+-----------------+-----------------------+-------------------------+ +----------------+-----------------------+--------------------------+
| Publish an | "A" sends or posts a | "B" reads a published | | Publish an | "A" sends or posts a | "B" reads a published |
| event | PUBLISH message | event | | event | PUBLISH message. | event. |
| | | | | | | |
| Publish an | "A" sends or posts a | "B" reads the updated | | Publish an | "A" sends or posts a | "B" reads the updated |
| updated event | PUBLISH message | event | | updated event | PUBLISH message. | event. |
| | | | | | | |
| Cancel a | "A" sends or posts a | "B" reads the canceled | | Cancel a | "A" sends or posts a | "B" reads the canceled |
| published event | CANCEL message | event publication | | published | CANCEL message. | event publication. |
+-----------------+-----------------------+-------------------------+ | event | | |
+----------------+-----------------------+--------------------------+
4.1.1. A Minimal Published Event 4.1.1. A Minimal Published Event
The iCalendar object below describes a single event that begins on The iCalendar object below describes a single event that begins on
July 1, 1997 at 20:00 UTC. This event contains the minimum set of July 1, 1997 at 20:00 UTC. This event contains the minimum set of
properties for a "PUBLISH" for a "VEVENT" calendar component. properties for a "PUBLISH" for a "VEVENT" calendar component.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:PUBLISH METHOD:PUBLISH
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
DTSTART:19970701T200000Z DTSTART:19970701T200000Z
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
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
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.1.2. Changing A Published Event 4.1.2. Changing a Published Event
The iCalendar object below describes an update to the event described The iCalendar object below describes an update to the event described
in 4.1.1, the time has been changed, an end time has been added, and in Section 4.1.1; the time has been changed, an end time has been
the sequence number has been adjusted. added, and the sequence number has been adjusted.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:PUBLISH METHOD:PUBLISH
VERSION:2.0 VERSION:2.0
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//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:1 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
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 a change to the event. "SEQUENCE" property indicates that this is a change to the event.
The event with a matching UID and sequence number 0 is superseded by The event with a matching "UID" and sequence number 0 is superseded
this event. by this event.
The "SEQUENCE" property provides a reliable way to distinguish The "SEQUENCE" property provides a reliable way to distinguish
different versions of the same event. Each time an event is different versions of the same event. Each time an event is
published, its sequence number is incremented. If a client receives published, its sequence number is incremented. If a client receives
an event with a sequence number 5 and finds it has the same event an event with a sequence number 5 and finds it has the same event
with sequence number 2, the event SHOULD be updated. However, if the with sequence number 2, the event SHOULD be updated. However, if the
client received an event with sequence number 2 and finds it already client received an event with sequence number 2 and finds it already
has sequence number 5 of the same event, the event MUST NOT be has sequence number 5 of the same event, the event MUST NOT be
updated. updated.
4.1.3. Canceling A Published Event 4.1.3. Canceling a Published Event
The iCalendar object below cancels the event described in 4.1.1. The iCalendar object below cancels the event described in
This cancels the event with "SEQUENCE" property of 0, 1, and 2. Section 4.1.1. This cancels the event with "SEQUENCE" property of 0,
1, and 2.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:CANCEL METHOD:CANCEL
VERSION:2.0 VERSION:2.0
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
COMMENT:DUKES forfeit the game COMMENT:DUKES forfeit the game
SEQUENCE:2 SEQUENCE:2
UID:0981234-1234234-23@example.com UID:0981234-1234234-23@example.com
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
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 This example describes the same event as in Section 4.1.1, but in
greater detail. much greater detail.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:PUBLISH METHOD:PUBLISH
SCALE:GREGORIAN SCALE:GREGORIAN
VERSION:2.0 VERSION:2.0
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America-Chicago TZID:America-Chicago
TZURL:http://example.com/tz/America-Chicago TZURL:http://example.com/tz/America-Chicago
BEGIN:STANDARD BEGIN:STANDARD
skipping to change at page 79, line 5 skipping to change at page 82, line 15
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.example.com/ ATTACH:http://www.example.com/
CATEGORIES:SPORTS EVENT,ENTERTAINMENT CATEGORIES:SPORTS EVENT,ENTERTAINMENT
CLASS:PRIVATE CLASS:PRIVATE
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
LOCATION;VALUE=URI:http://stadium.example.com/ LOCATION;VALUE=URI:http://stadium.example.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
skipping to change at page 79, line 34 skipping to change at page 83, line 5
TRIGGER:-PT30M TRIGGER:-PT30M
ACTION:AUDIO ACTION:AUDIO
END:VALARM END:VALARM
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The "RELATED-TO" field contains the "UID" property of a related The "RELATED-TO" field contains the "UID" property of a related
calendar event. The "SEQUENCE" property 3 indicates that this event calendar event. The "SEQUENCE" property 3 indicates that this event
supersedes versions 0, 1, and 2. supersedes 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 a day rather than a specific time.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:PUBLISH METHOD:PUBLISH
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
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
Group events are distinguished from published events in that they Group events are distinguished from published events in that they
have "Attendees" and that there is interaction between the have "Attendees" and there is interaction between the "Attendees" and
"Attendees" and the "Organizer" with respect to the event. the "Organizer" with respect to the event. Individual "A" requests a
Individual "A" requests a meeting between individuals "A", "B", "C" meeting between individuals "A", "B", "C", and "D". Individual "B"
and "D". Individual "B" confirms attendance to the meeting. confirms attendance to the meeting. Individual "C" declines
Individual "C" declines attendance. Individual "D" tentatively attendance. Individual "D" tentatively confirms attendance. The
confirms attendance. The following table illustrates the the message following table illustrates the message flow between these
flow between these individuals. A, the CU scheduling the meeting, is individuals. "A", the CU scheduling the meeting, is referenced as
referenced as the "Organizer". the "Organizer".
+--------------+-----------------------+----------------------------+ +--------------+-----------------------+----------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+--------------+-----------------------+----------------------------+ +--------------+-----------------------+----------------------------+
| Initiate a | "A" sends a REQUEST | | | Initiate a | "A" sends a REQUEST | |
| meeting | message to "B", "C", | | | meeting | message to "B", "C", | |
| request | and "D" | | | request | and "D". | |
| | | | | | | |
| Accept the | | "B" sends a REPLY message | | Accept the | | "B" sends a REPLY message |
| meeting | | to "A" with its ATTENDEE | | meeting | | to "A" with its ATTENDEE |
| request | | "PARTSTAT" parameter set | | request | | PARTSTAT parameter set to |
| | | to "ACCEPTED" | | | | ACCEPTED. |
| | | | | | | |
| Decline the | | "C" sends a REPLY message | | Decline the | | "C" sends a REPLY message |
| meeting | | to "A" with its ATTENDEE | | meeting | | to "A" with its ATTENDEE |
| request | | "PARTSTAT" parameter set | | request | | PARTSTAT parameter set to |
| | | to "DECLINED" | | | | DECLINED. |
| | | | | | | |
| Tentatively | | "D" sends a REPLY message | | Tentatively | | "D" sends a REPLY message |
| accept the | | to "A" with its ATTENDEE | | accept the | | to "A" with its ATTENDEE |
| meeting | | "PARTSTAT" parameter set | | meeting | | PARTSTAT parameter set to |
| request | | to "TENTATIVE" | | request | | TENTATIVE. |
| | | | | | | |
| Confirm | "A" sends a REQUEST | | | Confirm | "A" sends a REQUEST | |
| meeting | message to "B" and | | | meeting | message to "B" and | |
| status with | "D" with updated | | | status with | "D" with updated | |
| attendees | information. | | | Attendees | information. | |
+--------------+-----------------------+----------------------------+ +--------------+-----------------------+----------------------------+
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" 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 is also sent a copy of the request but is not expected to attend and
need not reply. "E" illustrates how CUAs might implement an "FYI" need not reply. "E" illustrates how CUAs might implement an "FYI"-
type feature. Note the use of the "ROLE" parameter. The default type feature. Note the use of the "ROLE" parameter. The default
value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not
be enumerated. In this case we are using the value "NON-PARTICIPANT" be enumerated. In this case, we are using the value "NON-
to indicate "E" is a non-attending CU. The parameter is not needed PARTICIPANT" to indicate "E" is a non-attending CU. The parameter is
on other "Attendees" since "PARTICIPANT" is the default value. not needed on other "Attendees" since "PARTICIPANT" is the default
value.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//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;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com
skipping to change at page 81, line 38 skipping to change at page 85, line 18
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T200000Z DTSTART:19970701T200000Z
DTEND:19970701T2100000Z DTEND:19970701T2100000Z
SUMMARY:Conference SUMMARY:Conference
UID:calsrv.example.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:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
UID:calsrv.example.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
"B" could have declined the meeting or indicated tentative acceptance "B" could have declined the meeting or indicated tentative acceptance
by setting the "ATTENDEE" "PARTSTAT" parameter to "DECLINED" or by setting the "ATTENDEE" "PARTSTAT" parameter to "DECLINED" or
"TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in "TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in
successful transactions. successful transactions.
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:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
skipping to change at page 83, line 8 skipping to change at page 86, line 24
SUMMARY:Phone Conference SUMMARY:Phone Conference
UID:calsrv.example.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 "A" sends a "REQUEST" to "B" and "C". "B" makes a counter proposal
to "A" to change the time and location. to "A" to change the time and location.
"A" sends the following "REQUEST": "A" sends the following "REQUEST":
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//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
skipping to change at page 83, line 35 skipping to change at page 87, line 7
LOCATION:Green Conference Room LOCATION:Green Conference Room
UID:calsrv.example.com-873970198738777a@example.com UID:calsrv.example.com-873970198738777a@example.com
SEQUENCE:0 SEQUENCE:0
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" sends "COUNTER" to "A", requesting changes to time and place.
"B" uses the "COMMENT" property to communicate a rationale for the "B" uses the "COMMENT" property to communicate a rationale for the
change. Note that the "SEQUENCE" property is NOT incremented on a change. Note that the "SEQUENCE" property is not incremented on a
"COUNTER". "COUNTER".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//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;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
skipping to change at page 84, line 26 skipping to change at page 87, line 31
DTSTAMP:19970612T190000Z DTSTAMP:19970612T190000Z
SUMMARY:Discuss the Merits of the election results SUMMARY:Discuss the Merits of the election results
LOCATION:Blue Conference Room LOCATION:Blue 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:calsrv.example.com-873970198738777a@example.com UID:calsrv.example.com-873970198738777a@example.com
SEQUENCE:0 SEQUENCE:0
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:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//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;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
skipping to change at page 85, line 5 skipping to change at page 88, line 7
DTEND:19970701T170000Z DTEND:19970701T170000Z
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:Blue Conference Room LOCATION:Blue Conference Room
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:1 SEQUENCE:1
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:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//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;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
COMMENT:Sorry, I cannot change this meeting time COMMENT:Sorry, I cannot change this meeting time
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
skipping to change at page 85, line 28 skipping to change at page 88, line 30
END:VEVENT END:VEVENT
END:VCALENDAR 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 "Delegator" must both update the "Organizer" with a "REPLY" and send
a request to the "Delegate". There is currently no protocol a request to the "Delegate". There is currently no protocol
limitation to delegation depth. It is possible for the original limitation to delegation depth. It is possible for the original
delegate to delegate the meeting to someone else, and so on. When a delegate to delegate the meeting to someone else, and so on. When a
request is delegated from one CUA to another there are a number of request is delegated from one CUA to another, there are a number of
responsibilities required of the "Delegator". The "Delegator" MUST: responsibilities required of the "Delegator". The "Delegator" MUST:
o Send a "REPLY" to the "Organizer" with the following updates: o Send a "REPLY" to the "Organizer" with the following updates:
A. The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter set
to "DELEGATED" and the "DELEGATED-TO" parameter is set to the A. The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter is
address of the "Delegate" set to "DELEGATED" and the "DELEGATED-TO" parameter is set to
the address of the "Delegate".
B. Add an additional "ATTENDEE" property for the "Delegate" with B. Add an additional "ATTENDEE" property for the "Delegate" with
the "DELEGATED-FROM" property parameter set to the "Delegator" the "DELEGATED-FROM" property parameter set to the
"Delegator".
C. Indicate whether they want to continue to receive updates when C. Indicate whether they want to continue to receive updates when
the "Organizer" sends out updated versions of the event. the "Organizer" sends out updated versions of the event.
Setting the "RSVP" property parameter to "TRUE" will cause the 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; setting it to "FALSE" causes no further
updates to be sent. Note that in either case, if the updates to be sent. Note that in either case, if the
"Delegate" declines the invitation the "Delegator" will be "Delegate" declines the invitation, the "Delegator" will be
notified. notified.
o The "Delegator" MUST also send a copy of the original "REQUEST" o The "Delegator" MUST also send a copy of the original "REQUEST"
method to the "Delegate", with changes (A) and (B) as detailed method to the "Delegate", with changes (A) and (B), as detailed
above applied. above applied.
If the "Delegate" declines the meeting, the "Organizer" MUST send an If the "Delegate" declines the meeting, the "Organizer" MUST send an
update "REQUEST" to the "Delegator" so that the "Delegator" may elect update "REQUEST" to the "Delegator" so that the "Delegator" may elect
to delegate the "REQUEST" to another CUA. to delegate the "REQUEST" to another CUA.
+-----------------+----------------+--------------------------------+ +----------------+-----------------+--------------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+-----------------+----------------+--------------------------------+ +----------------+-----------------+--------------------------------+
| Initiate a | "A" sends a | | | Initiate a | "A" sends a | |
| meeting request | REQUEST | | | meeting | REQUEST message | |
| | message to "B" | | | request | to "B" and "C". | |
| | and "C" | | | | | |
| | | | | Delegate: "C" | | "C" sends a REPLY to "A" with |
| Delegate: "C" | | "C" sends a REPLY to "A" with | | delegates to | | the ATTENDEE PARTSTAT |
| delegates to | | the ATTENDEE "PARTSTAT" | | "E" | | parameter set to DELEGATED and |
| "E" | | parameter set to "DELEGATED" | | | | with a new ATTENDEE property |
| | | and with a new "ATTENDEE" | | | | for "E". "E's" ATTENDEE |
| | | property for "E". "E's" | | | | DELEGATED-FROM parameter is |
| | | ATTENDEE "DELEGATED-FROM" | | | | set to "C". "C's" ATTENDEE |
| | | parameter is set to "C". | | | | DELEGATED-TO parameter is set |
| | | "C's" ATTENDEE "DELEGATED-TO" | | | | to "E". "C" sends REQUEST |
| | | parameter is set to "E". "C" | | | | message to "E" with the |
| | | sends REQUEST message to "E" | | | | original meeting request |
| | | with the original meeting | | | | information. The PARTSTAT |
| | | request information. The | | | | property parameter for "C" is |
| | | "PARTSTAT" property parameter | | | | set to DELEGATED and the |
| | | for "C" is set to "DELEGATED" | | | | DELEGATED-TO parameter is set |
| | | and the "DELEGATED-TO" | | | | to the address of "E". An |
| | | parameter is set to the | | | | ATTENDEE property is added for |
| | | address of "E". An "ATTENDEE" | | | | "E" and the DELEGATED-FROM |
| | | property is added for "E" and | | | | parameter is set to the |
| | | the "DELEGATED-FROM" parameter | | | | address of "C". |
| | | is set to the address of "C". | | | | |
| | | | | Confirm | | "E" sends REPLY message to |
| Confirm meeting | | "E" sends REPLY message to "A" | | meeting | | "A", and optionally to "C", |
| attendance | | and optionally "C" with its | | attendance | | with its PARTSTAT property |
| | | "PARTSTAT" property parameter | | | | parameter set to ACCEPTED. |
| | | set to "ACCEPTED" | | | | |
| | | | | Optional: | "A" sends | |
| Optional: | "A" sends | | | Redistribute | REQUEST message | |
| Redistribute | REQUEST | | | meeting to | to "B", "C", | |
| meeting to | message to | | | Attendees | and "E". | |
| attendees | "B", "C" and | | +----------------+-----------------+--------------------------------+
| | "E". | |
+-----------------+----------------+--------------------------------+
"C" responds to the "Organizer". "C" responds to the "Organizer".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//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;PARTSTAT=DELEGATED;DELEGATED- ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
TO="mailto:e@example.com":mailto:c@example.com TO="mailto:e@example.com":mailto:c@example.com
UID:calsrv.example.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: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:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//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;PARTSTAT=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;RSVP=TRUE; ATTENDEE;RSVP=TRUE;
skipping to change at page 87, line 45 skipping to change at page 90, line 46
UID:calsrv.example.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:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//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;PARTSTAT=ACCEPTED;DELEGATED- ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
FROM="mailto:c@example.com":mailto:e@example.com FROM="mailto:c@example.com":mailto:e@example.com
ATTENDEE;PARTSTAT=DELEGATED; ATTENDEE;PARTSTAT=DELEGATED;
DELEGATED-TO="mailto:e@example.com":mailto:c@example.com DELEGATED-TO="mailto:e@example.com":mailto:c@example.com
UID:calsrv.example.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:19970614T190000Z DTSTAMP:19970614T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
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 In this example, the "Delegate" declines the meeting request and sets
the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The
"Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT" "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT"
parameter of the "Delegate" set to "DECLINED". This lets the parameter of the "Delegate" set to "DECLINED". This lets the
"Delegator" know that the "Delegate" has declined and provides an "Delegator" know that the "Delegate" has declined and provides an
opportunity to the "Delegator" to either accept the request or opportunity to the "Delegator" to either accept the request or
delegate it to another CU. delegate it to another CU.
Response from "E" to "A" and "C". Note the use of the "COMMENT" "E" responds to "A" and "C". Note the use of the "COMMENT" property
property "E" uses to indicate why the delegation was declined. "E" uses to indicate why the delegation was declined.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//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;PARTSTAT=DELEGATED; ATTENDEE;PARTSTAT=DELEGATED;
DELEGATED-TO="mailto:e@example.com":mailto:c@example.com DELEGATED-TO="mailto:e@example.com":mailto:c@example.com
ATTENDEE;PARTSTAT=DECLINED; ATTENDEE;PARTSTAT=DECLINED;
skipping to change at page 89, line 32 skipping to change at page 92, line 27
DTSTART:19970701T180000Z DTSTART:19970701T180000Z
DTEND:19970701T200000Z 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
END:VCALENDAR END:VCALENDAR
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" a
"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 Crasher" to the "Attendee" list, and hence there is no guarantee that
a "Party Crasher" will receive additional updates to the event. The a "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
attendee list. The "Organizer" MAY add the forwarded "Calendar User" "Attendee" list. The "Organizer" MAY add the forwarded "Calendar
to the attendee list. User" to the "Attendee" list.
4.2.9. Cancel A Group Event 4.2.9. Cancel a Group Event
Individual "A" requests a meeting between individuals "A", "B", "C", Individual "A" requests a meeting between individuals "A", "B", "C",
and "D". Individual "B" declines attendance to the meeting. and "D". Individual "B" declines attendance to the meeting.
Individual "A" decides to cancel the meeting. The following table Individual "A" decides to cancel the meeting. The following table
illustrates the sequence of messages that would be exchanged between illustrates the sequence of messages that would be exchanged between
these individuals. these individuals.