aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/rfc5546.txt
diff options
context:
space:
mode:
authorfriendica <info@friendica.com>2013-10-21 15:46:31 -0700
committerfriendica <info@friendica.com>2013-10-21 15:46:31 -0700
commitb35122f7a6ad42756c35bb60ba1f06c3dcd45c77 (patch)
treeccdf373ce6475d264778523259cc32899b732fe7 /vendor/sabre/dav/docs/rfc5546.txt
parente3504df514d306cfe6b83e44a11f550664564af4 (diff)
downloadvolse-hubzilla-b35122f7a6ad42756c35bb60ba1f06c3dcd45c77.tar.gz
volse-hubzilla-b35122f7a6ad42756c35bb60ba1f06c3dcd45c77.tar.bz2
volse-hubzilla-b35122f7a6ad42756c35bb60ba1f06c3dcd45c77.zip
add sabre (1.8.x) via composer in the !@#$ place it wants to be
Diffstat (limited to 'vendor/sabre/dav/docs/rfc5546.txt')
-rw-r--r--vendor/sabre/dav/docs/rfc5546.txt7451
1 files changed, 7451 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/rfc5546.txt b/vendor/sabre/dav/docs/rfc5546.txt
new file mode 100644
index 000000000..80361d81a
--- /dev/null
+++ b/vendor/sabre/dav/docs/rfc5546.txt
@@ -0,0 +1,7451 @@
+
+
+
+
+
+
+Network Working Group C. Daboo, Ed.
+Request for Comments: 5546 Apple Inc.
+Obsoletes: 2446 December 2009
+Updates: 5545
+Category: Standards Track
+
+
+ iCalendar Transport-Independent Interoperability Protocol (iTIP)
+
+Abstract
+
+ This document specifies a protocol that uses the iCalendar object
+ 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 that use specific, interoperable methods of
+ communication between systems.
+
+ The iCalendar Transport-Independent Interoperability Protocol (iTIP)
+ 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.
+
+Status of This Memo
+
+ 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 (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+
+
+
+
+
+Daboo Standards Track [Page 1]
+
+RFC 5546 iTIP December 2009
+
+
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction and Overview .......................................5
+ 1.1. Formatting Conventions .....................................5
+ 1.2. Related Documents ..........................................6
+ 1.3. Roles ......................................................6
+ 1.4. Methods ....................................................7
+ 2. Interoperability Models .........................................9
+ 2.1. Application Protocol ......................................10
+ 2.1.1. Scheduling State ...................................10
+ 2.1.2. Delegation .........................................10
+ 2.1.3. Acting on Behalf of Other Calendar Users ...........11
+ 2.1.4. Component Revisions ................................11
+ 2.1.5. Message Sequencing .................................12
+ 3. Application Protocol Elements ..................................13
+ 3.1. Common Component Restriction Tables .......................15
+ 3.1.1. VCALENDAR ..........................................15
+ 3.1.2. VTIMEZONE ..........................................15
+ 3.1.3. VALARM .............................................17
+ 3.2. Methods for VEVENT Calendar Components ....................17
+ 3.2.1. PUBLISH ............................................18
+ 3.2.2. REQUEST ............................................20
+ 3.2.3. REPLY ..............................................25
+ 3.2.4. ADD ................................................27
+ 3.2.5. CANCEL .............................................29
+ 3.2.6. REFRESH ............................................31
+ 3.2.7. COUNTER ............................................33
+ 3.2.8. DECLINECOUNTER .....................................35
+ 3.3. Methods for VFREEBUSY Components ..........................37
+ 3.3.1. PUBLISH ............................................37
+ 3.3.2. REQUEST ............................................40
+ 3.3.3. REPLY ..............................................42
+
+
+
+Daboo Standards Track [Page 2]
+
+RFC 5546 iTIP December 2009
+
+
+ 3.4. Methods for VTODO Components ..............................44
+ 3.4.1. PUBLISH ............................................44
+ 3.4.2. REQUEST ............................................46
+ 3.4.3. REPLY ..............................................51
+ 3.4.4. ADD ................................................53
+ 3.4.5. CANCEL .............................................55
+ 3.4.6. REFRESH ............................................57
+ 3.4.7. COUNTER ............................................59
+ 3.4.8. DECLINECOUNTER .....................................61
+ 3.5. Methods for VJOURNAL Components ...........................62
+ 3.5.1. PUBLISH ............................................63
+ 3.5.2. ADD ................................................64
+ 3.5.3. CANCEL .............................................66
+ 3.6. Status Replies ............................................68
+ 3.7. Implementation Considerations .............................77
+ 3.7.1. Working With Recurrence Instances ..................77
+ 3.7.2. Attendee Property Considerations ...................78
+ 3.7.3. Extension Tokens ...................................79
+ 4. Examples .......................................................79
+ 4.1. Published Event Examples ..................................79
+ 4.1.1. A Minimal Published Event ..........................80
+ 4.1.2. Changing a Published Event .........................80
+ 4.1.3. Canceling a Published Event ........................81
+ 4.1.4. A Rich Published Event .............................81
+ 4.1.5. Anniversaries or Events Attached to Entire Days ....83
+ 4.2. Group Event Examples ......................................83
+ 4.2.1. A Group Event Request ..............................84
+ 4.2.2. Reply to a Group Event Request .....................85
+ 4.2.3. Update an Event ....................................85
+ 4.2.4. Countering an Event Proposal .......................86
+ 4.2.5. Delegating an Event ................................88
+ 4.2.6. Delegate Accepts the Meeting .......................90
+ 4.2.7. Delegate Declines the Meeting ......................91
+ 4.2.8. Forwarding an Event Request ........................92
+ 4.2.9. Cancel a Group Event ...............................92
+ 4.2.10. Removing Attendees ................................93
+ 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
+
+
+
+Daboo Standards Track [Page 3]
+
+RFC 5546 iTIP December 2009
+
+
+ 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
+
+
+
+Daboo Standards Track [Page 4]
+
+RFC 5546 iTIP December 2009
+
+
+ Appendix A. Differences from RFC 2446 ...........................132
+ A.1. Changed Restrictions .....................................132
+ A.2. Deprecated Features ......................................133
+
+1. Introduction and Overview
+
+ This document specifies how calendaring systems use iCalendar
+ [RFC5545] objects to interoperate with other calendaring systems. In
+ particular, it specifies how to schedule events, to-dos, or daily
+ journal entries. It further specifies how to search for available
+ busy time information. It does so in a general way, without
+ specifying how communication between different systems actually takes
+ place. Subsequent documents will specify transport bindings between
+ systems that use this protocol.
+
+ This protocol is based on messages sent from an originator to one or
+ more recipients. For certain types of messages, a recipient may
+ reply in order to update their status and may also return
+ transaction/request status information. The protocol supports the
+ ability for the message originator to modify or cancel the original
+ message. The protocol also supports the ability for recipients to
+ suggest changes to the originator of a message. The elements of the
+ protocol also define the user roles for its transactions.
+
+ This specification obsoletes RFC 2446 - a list of important changes
+ is provided in Appendix A.
+
+1.1. Formatting Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ Calendaring and scheduling roles are referred to in quoted-strings of
+ text with the first character of each word in upper case. For
+ example, "Organizer" refers to a role of a "Calendar User" (CU)
+ within the scheduling protocol.
+
+ Calendar components defined by [RFC5545] are referred to with
+ capitalized, quoted-strings of text. All calendar components start
+ with the letter "V". For example, "VEVENT" refers to the event
+ calendar component, "VTODO" refers to the to-do calendar component,
+ and "VJOURNAL" refers to the daily journal calendar component.
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 5]
+
+RFC 5546 iTIP December 2009
+
+
+ Scheduling methods are referred to with capitalized, quoted-strings
+ of text. For example, "REQUEST" refers to the method for requesting
+ a scheduling calendar component be created or modified; "REPLY"
+ refers to the method a recipient of a request uses to update their
+ status with the "Organizer" of the calendar component.
+
+ Properties defined by [RFC5545] are referred to with capitalized,
+ quoted-strings of text, followed by the word "property". For
+ example, "ATTENDEE" property refers to the iCalendar property used to
+ convey the calendar address of a "Calendar User".
+
+ Property parameters defined by this specification are referred to
+ with capitalized, quoted-strings of text, followed by the word
+ "parameter". For example, "VALUE" parameter refers to the iCalendar
+ property parameter used to override the default data type for a
+ property value.
+
+ Enumerated values defined by this specification are referred to with
+ capitalized text, either alone or followed by the word "value".
+
+ In tables, the quoted-string text is specified without quotes in
+ order to minimize the table length.
+
+1.2. Related Documents
+
+ Implementers will need to be familiar with several other
+ specifications that, along with this one, describe the Internet
+ calendaring and scheduling standards. The related documents are:
+
+ [RFC5545] - specifies the objects, data types, properties, and
+ property parameters used in the protocols, along with the methods
+ for representing and encoding them.
+
+ [iMIP] - specifies an Internet email binding for iTIP.
+
+ This specification does not attempt to repeat the concepts or
+ definitions from these other specifications. Where possible,
+ explicit references are made to the other specifications.
+
+1.3. Roles
+
+ Exchanges of iCalendar objects for the purposes of group calendaring
+ and scheduling occur between "Calendar Users" (CUs). CUs take on
+ several roles in iTIP:
+
+
+
+
+
+
+
+Daboo Standards Track [Page 6]
+
+RFC 5546 iTIP December 2009
+
+
+ +-----------+-------------------------------------------------------+
+ | Role | Description |
+ +-----------+-------------------------------------------------------+
+ | Organizer | The CU who initiates an exchange takes on the role of |
+ | | Organizer. For example, the CU who proposes a group |
+ | | meeting is the Organizer. |
+ | | |
+ | Attendee | CUs who are included in the scheduling message as |
+ | | possible recipients of that scheduling message. For |
+ | | example, the CUs asked to participate in a group |
+ | | meeting by the Organizer take on the role of |
+ | | Attendee. |
+ | | |
+ | Other CU | A CU that is not explicitly included in a scheduling |
+ | | message, i.e., not the Organizer or an Attendee. |
+ +-----------+-------------------------------------------------------+
+
+ Note that "ROLE" is also a descriptive parameter to the iCalendar
+ "ATTENDEE" property. Its use is to convey descriptive context about
+ an "Attendee" -- such as "chair", "required participant", or "non-
+ required participant" -- and has nothing to do with the calendaring
+ workflow.
+
+1.4. Methods
+
+ The iTIP methods are listed below and their usage and semantics are
+ defined in Section 3 of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 7]
+
+RFC 5546 iTIP December 2009
+
+
+ +----------------+--------------------------------------------------+
+ | Method | Description |
+ +----------------+--------------------------------------------------+
+ | PUBLISH | Used to publish an iCalendar object to one or |
+ | | more "Calendar Users". There is no |
+ | | interactivity between the publisher and any |
+ | | other "Calendar User". An example might include |
+ | | a baseball team publishing its schedule to the |
+ | | public. |
+ | | |
+ | REQUEST | Used to schedule an iCalendar object with other |
+ | | "Calendar Users". Requests are interactive in |
+ | | that they require the receiver to respond using |
+ | | the reply methods. Meeting requests, busy-time |
+ | | requests, and the assignment of tasks to other |
+ | | "Calendar Users" are all examples. Requests are |
+ | | also used by the Organizer to update the status |
+ | | of an iCalendar object. |
+ | | |
+ | REPLY | A reply is used in response to a request to |
+ | | convey Attendee status to the Organizer. |
+ | | Replies are commonly used to respond to meeting |
+ | | and task requests. |
+ | | |
+ | ADD | Add one or more new instances to an existing |
+ | | recurring iCalendar object. |
+ | | |
+ | CANCEL | Cancel one or more instances of an existing |
+ | | iCalendar object. |
+ | | |
+ | REFRESH | Used by an Attendee to request the latest |
+ | | version of an iCalendar object. |
+ | | |
+ | COUNTER | Used by an Attendee to negotiate a change in an |
+ | | iCalendar object. Examples include the request |
+ | | to change a proposed event time or change the |
+ | | due date for a task. |
+ | | |
+ | DECLINECOUNTER | Used by the Organizer to decline the proposed |
+ | | counter proposal. |
+ +----------------+--------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 8]
+
+RFC 5546 iTIP December 2009
+
+
+ Group scheduling in iTIP is accomplished using the set of "request"
+ and "response" methods described above. The following table shows
+ the methods broken down by who can send them.
+
+ +------------+------------------------------------------------------+
+ | Originator | Methods |
+ +------------+------------------------------------------------------+
+ | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER |
+ | | |
+ | Attendee | REPLY, REFRESH, COUNTER, REQUEST (only when |
+ | | delegating) |
+ +------------+------------------------------------------------------+
+
+ Note that for some calendar component types, the allowable methods
+ are a subset of the above set. In addition, apart from "VTIMEZONE"
+ iCalendar components, only one component type is allowed in a single
+ iTIP message.
+
+2. Interoperability Models
+
+ There are two distinct protocols relevant to interoperability: an
+ "application protocol" and a "transport protocol". The application
+ protocol defines the content of the iCalendar objects sent between
+ sender and receiver to accomplish the scheduling transactions listed
+ above. The transport protocol defines how the iCalendar objects are
+ sent between the sender and receiver. This document focuses on the
+ application protocol. Binding documents such as [iMIP] focus on the
+ transport protocol.
+
+ The connection between sender and receiver in the diagram below
+ refers to the application protocol. The iCalendar objects passed
+ from the sender to the receiver are presented in Section 3,
+ "Application Protocol Elements".
+
+ +----------+ +----------+
+ | | iTIP | |
+ | Sender |<-------------->| Receiver |
+ | | | |
+ +----------+ +----------+
+
+ 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
+ "Calendar Service" (CS).
+
+ The architecture of iTIP is depicted in the diagram below. An
+ application written to this specification may work with bindings for
+ the store-and-forward transport, the real-time transport, or both.
+ Also note that iTIP could be bound to other transports.
+
+
+
+Daboo Standards Track [Page 9]
+
+RFC 5546 iTIP December 2009
+
+
+ +--------------------------------------------------------+
+ | iTIP Protocol |
+ +--------------------------------------------------------+
+ | Transport |
+ + - - - - - + - - - - - - + - - - - - +
+ | Real-Time | Store-and-Forward | Others |
+ +-----------------+--------------------+-----------------+
+
+2.1. Application Protocol
+
+ In the iTIP model, an iCalendar object is created and managed by an
+ "Organizer". The "Organizer" interacts with other CUs by sending one
+ or more of the iTIP messages listed above. "Attendees" use the
+ "REPLY" method to communicate their status. "Attendees" do not make
+ direct changes to the master iCalendar object. They can, however,
+ use the "COUNTER" method to suggest changes to the "Organizer". In
+ any case, the "Organizer" has complete control over the master
+ iCalendar object.
+
+2.1.1. Scheduling State
+
+ There are two distinct states relevant to iCalendar objects used in
+ scheduling: the overall state of the iCalendar object and the state
+ associated with an "Attendee" in that iCalendar object.
+
+ The state of an iCalendar object is defined by the "STATUS" property
+ and is controlled by the "Organizer." There is no default value for
+ the "STATUS" property. The "Organizer" sets the "STATUS" property to
+ the appropriate value for each iCalendar object.
+
+ The state of a particular "Attendee" relative to an iCalendar object
+ used for scheduling is defined by the "PARTSTAT" parameter in the
+ "ATTENDEE" property for each "Attendee". When an "Organizer" issues
+ the initial iCalendar object, "Attendee" status is typically unknown.
+ The "Organizer" specifies this by setting the "PARTSTAT" parameter to
+ "NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" property
+ "PARTSTAT" parameter to an appropriate value as part of a "REPLY"
+ message sent back to the "Organizer".
+
+2.1.2. Delegation
+
+ Delegation is defined as the process by which an "Attendee" grants
+ another CU (or several CUs) the right to attend on their behalf. The
+ "Organizer" is made aware of this change because the delegating
+ "Attendee" informs the "Organizer". These steps are detailed in the
+ "REQUEST" method sections for the appropriate components.
+
+
+
+
+
+Daboo Standards Track [Page 10]
+
+RFC 5546 iTIP December 2009
+
+
+2.1.3. Acting on Behalf of Other Calendar Users
+
+ In many organizations, one user will act on behalf of another to
+ organize and/or respond to meeting requests. iTIP provides two
+ mechanisms that support these activities.
+
+ First, the "Organizer" is treated as a special entity, separate from
+ "Attendees". All responses from "Attendees" flow to the "Organizer",
+ making it easy to separate a "Calendar User" organizing a meeting
+ from "Calendar Users" attending the meeting. Additionally, iCalendar
+ provides descriptive roles for each "Attendee". For instance, a role
+ 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
+ maps well to scenarios where an assistant may manage meeting
+ logistics for another individual who chairs a meeting.
+
+ Second, a "SENT-BY" parameter may be specified in either the
+ "Organizer" or "Attendee" properties. When specified, the "SENT-BY"
+ parameter indicates that the responding CU acted on behalf of the
+ specified "Attendee" or "Organizer".
+
+2.1.4. Component Revisions
+
+ The "SEQUENCE" property is used by the "Organizer" to indicate
+ revisions to the calendar component. When the "Organizer" makes
+ changes to one of the following properties, the sequence number MUST
+ be incremented:
+
+ o "DTSTART"
+
+ o "DTEND"
+
+ o "DURATION"
+
+ o "DUE"
+
+ o "RRULE"
+
+ o "RDATE"
+
+ o "EXDATE"
+
+ o "STATUS"
+
+ In addition, changes made by the "Organizer" to other properties MAY
+ also require the sequence number to be incremented. The "Organizer"
+ CUA MUST increment the sequence number whenever it makes changes to
+ properties in the calendar component that the "Organizer" deems will
+
+
+
+Daboo Standards Track [Page 11]
+
+RFC 5546 iTIP December 2009
+
+
+ jeopardize the validity of the participation status of the
+ "Attendees". For example, changing the location of a meeting from
+ one location to another distant location could effectively impact the
+ participation status of the "Attendees".
+
+ Depending on the "METHOD", the "SEQUENCE" property MUST follow these
+ rules in the context of iTIP:
+
+ o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
+ value is incremented according to the rules stated above.
+
+ o The "SEQUENCE" property value MUST be incremented each time the
+ "Organizer" uses the "ADD" or "CANCEL" methods.
+
+ o The "SEQUENCE" property value MUST NOT be incremented when using
+ "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
+ delegation "REQUEST".
+
+ In some circumstances, the "Organizer" may not have received
+ responses to the final revision sent out. In this situation, the
+ "Organizer" may wish to send an update "REQUEST" and set "RSVP=TRUE"
+ for all "Attendees" so that current responses can be collected.
+
+ The value of the "SEQUENCE" property contained in a response from an
+ "Attendee" may not always match the "Organizer's" revision.
+ Implementations may choose to have the CUA indicate to the CU that
+ the response is to an iCalendar object that has been revised, and
+ allow the CU to decide whether or not to accept the response.
+
+ Whilst a change in sequence number is indicative of a significant
+ change to a previously scheduled item, "Attendee" CUAs SHOULD NOT
+ rely solely on a change in sequence number as a means of detecting a
+ significant change. Instead, CUAs SHOULD compare the old and new
+ versions of the calendar components, determine the exact nature of
+ the changes, and make decisions -- possibly based on "Calendar User"
+ preferences -- as to whether the user needs to be explicitly informed
+ of the change.
+
+2.1.5. Message Sequencing
+
+ CUAs that handle the iTIP application protocol must often correlate a
+ component in a calendar store with a component received in the iTIP
+ message. For example, an event may be updated with a later revision
+ of the same event. To accomplish this, a CUA must correlate the
+ version of the event already in its calendar store with the version
+ sent in the iTIP message. In addition to this correlation, there are
+ several factors that can cause iTIP messages to arrive in an
+ unexpected order. That is, an "Organizer" could receive a reply to
+
+
+
+Daboo Standards Track [Page 12]
+
+RFC 5546 iTIP December 2009
+
+
+ an earlier revision of a component after receiving a reply to a later
+ revision.
+
+ To maximize interoperability and to handle messages that arrive in an
+ unexpected order, use the following rules:
+
+ 1. The primary key for referencing a particular iCalendar component
+ is the "UID" property value. To reference an instance of a
+ recurring component, the primary key is composed of the "UID" and
+ the "RECURRENCE-ID" properties.
+
+ 2. The secondary key for referencing a component is the "SEQUENCE"
+ property value. For components where the "UID" and
+ "RECURRENCE-ID" property values are the same, the component with
+ the highest numeric value for the "SEQUENCE" property obsoletes
+ all other revisions of the component with lower values.
+
+ 3. "Attendees" send "REPLY" messages to the "Organizer". For
+ replies where the "UID" and "RECURRENCE-ID" property values are
+ the same, the value of the "SEQUENCE" property indicates the
+ revision of the component to which the "Attendee" is replying.
+ The reply with the highest numeric value for the "SEQUENCE"
+ property obsoletes all other replies with lower values.
+
+ 4. In situations where the "UID", "RECURRENCE-ID", and "SEQUENCE"
+ property values match, the "DTSTAMP" property is used as the tie-
+ breaker. The component with the latest "DTSTAMP" overrides all
+ others. Similarly, for "Attendee" responses where the "UID",
+ "RECURRENCE-ID", and "SEQUENCE" property values match, the
+ response with the latest "DTSTAMP" overrides all others.
+
+ Hence, CUAs will need to persist the following component properties
+ in order to correctly process iTIP messages: "UID", "RECURRENCE-ID",
+ "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property
+ of a component, "Organizer" CUAs will need to persist the "SEQUENCE"
+ and "DTSTAMP" property values associated with the "Attendee's" last
+ response, so that any earlier responses from an "Attendee" that are
+ received out of order (e.g., due to a delay in the transport) can be
+ correctly discarded.
+
+3. Application Protocol Elements
+
+ iTIP messages are "text/calendar" MIME entities that contain
+ calendaring and scheduling information. The particular type of
+ iCalendar message is referred to as the "method type". Each method
+ type is identified by a "METHOD" property specified as part of the
+ "text/calendar" content type. The table below shows various
+
+
+
+
+Daboo Standards Track [Page 13]
+
+RFC 5546 iTIP December 2009
+
+
+ combinations of calendar components and the method types that this
+ specification supports.
+
+ +----------------+--------+-------+----------+-----------+
+ | | VEVENT | VTODO | VJOURNAL | VFREEBUSY |
+ +----------------+--------+-------+----------+-----------+
+ | PUBLISH | Yes | Yes | Yes | Yes |
+ | REQUEST | Yes | Yes | No | Yes |
+ | REFRESH | Yes | Yes | No | No |
+ | CANCEL | Yes | Yes | Yes | No |
+ | ADD | Yes | Yes | Yes | No |
+ | REPLY | Yes | Yes | No | Yes |
+ | COUNTER | Yes | Yes | No | No |
+ | DECLINECOUNTER | Yes | Yes | No | No |
+ +----------------+--------+-------+----------+-----------+
+
+ Each method type is defined in terms of its associated components and
+ properties. Some components and properties are required, some are
+ optional, and others are excluded. The restrictions are expressed in
+ this document using a simple "restriction table". The first column
+ indicates the name of a component or property. Properties of the
+ iCalendar object are not indented. Properties of a component are
+ indented. The second column (the "Presence" column) indicates
+ whether or not a component or property should be present and, if
+ present, how many times it can occur. The third column contains
+ comments for further clarification.
+
+ The presence column uses the following values to assert whether a
+ property is required or optional, and the number of times it may
+ appear in the iCalendar object.
+
+ +----------------+--------------------------------------------------+
+ | Presence Value | Description |
+ +----------------+--------------------------------------------------+
+ | 1 | One instance MUST be present. |
+ | 1+ | At least one instance MUST be present. |
+ | 0 | Instances of this property MUST NOT be present. |
+ | 0+ | Multiple instances MAY be present. |
+ | 0 or 1 | Up to 1 instance of this property MAY be |
+ | | present. |
+ +----------------+--------------------------------------------------+
+
+ The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA-
+ COMPONENT", and "X-COMPONENT" to show where registered and
+ experimental property and component extensions can appear. The
+ tables do not lay out the restrictions of property parameters. Those
+ restrictions are defined in [RFC5545].
+
+
+
+
+Daboo Standards Track [Page 14]
+
+RFC 5546 iTIP December 2009
+
+
+3.1. Common Component Restriction Tables
+
+3.1.1. VCALENDAR
+
+ The restriction table below applies to properties of the iCalendar
+ object. That is, the properties at the outermost scope.
+
+ +-----------------------------------------------------+
+ | Constraints for Properties in a VCALENDAR Component |
+ +-----------------------------------------------------+
+
+ +--------------------+----------+--------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+--------------------+
+ | CALSCALE | 0 or 1 | |
+ | PRODID | 1 | |
+ | VERSION | 1 | Value MUST be 2.0. |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ +--------------------+----------+--------------------+
+
+3.1.2. VTIMEZONE
+
+ "VTIMEZONE" components may be referred to by other components via a
+ "TZID" parameter on a "DATETIME" value type. The property
+ restrictions in the table below apply to any "VTIMEZONE" component in
+ an iTIP message.
+
+ +--------------------------------------+
+ | Constraints for VTIMEZONE Components |
+ +--------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 15]
+
+RFC 5546 iTIP December 2009
+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to timezone. |
+ | DAYLIGHT | 0+ | MUST be one or more of either |
+ | | | STANDARD or DAYLIGHT. |
+ | COMMENT | 0+ | |
+ | DTSTART | 1 | MUST be local time format. |
+ | RDATE | 0+ | |
+ | RRULE | 0 or 1 | |
+ | TZNAME | 0+ | |
+ | TZOFFSETFROM | 1 | |
+ | TZOFFSETTO | 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | STANDARD | 0+ | MUST be one or more of either |
+ | | | STANDARD or DAYLIGHT. |
+ | COMMENT | 0+ | |
+ | DTSTART | 1 | MUST be local time format. |
+ | RDATE | 0+ | If present, RRULE MUST NOT be |
+ | | | present. |
+ | RRULE | 0 or 1 | If present, RDATE MUST NOT be |
+ | | | present. |
+ | TZNAME | 0+ | |
+ | TZOFFSETFROM | 1 | |
+ | TZOFFSETTO | 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | TZID | 1 | |
+ | TZURL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 16]
+
+RFC 5546 iTIP December 2009
+
+
+3.1.3. VALARM
+
+ The property restrictions in the table below apply to any "VALARM"
+ component in an iTIP message.
+
+ +-----------------------------------+
+ | Constraints for VALARM Components |
+ +-----------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | VALARM | 0+ | |
+ | ACTION | 1 | |
+ | ATTACH | 0+ | |
+ | ATTENDEE | 0+ | |
+ | DESCRIPTION | 0 or 1 | |
+ | DURATION | 0 or 1 | If present, REPEAT MUST be |
+ | | | present. |
+ | REPEAT | 0 or 1 | If present, DURATION MUST be |
+ | | | present. |
+ | SUMMARY | 0 or 1 | |
+ | TRIGGER | 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ +--------------------+----------+-----------------------------------+
+
+3.2. Methods for VEVENT Calendar Components
+
+ This section defines the property set restrictions for the method
+ types that are applicable to the "VEVENT" calendar component. Each
+ method is defined using a table that clarifies the property
+ constraints that define the particular method.
+
+ The following summarizes the methods that are defined for the
+ "VEVENT" calendar component.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 17]
+
+RFC 5546 iTIP December 2009
+
+
+ +----------------+--------------------------------------------------+
+ | Method | Description |
+ +----------------+--------------------------------------------------+
+ | PUBLISH | Post notification of an event. Used primarily |
+ | | as a method of advertising the existence of an |
+ | | event. |
+ | | |
+ | REQUEST | Make a request for an event. This is an |
+ | | explicit invitation to one or more Attendees. |
+ | | Event requests are also used to update or change |
+ | | an existing event. Clients that cannot handle |
+ | | REQUEST MAY degrade the event to view it as a |
+ | | PUBLISH. |
+ | | |
+ | REPLY | Reply to an event request. Clients may set |
+ | | their status (PARTSTAT) to ACCEPTED, DECLINED, |
+ | | TENTATIVE, or DELEGATED. |
+ | | |
+ | ADD | Add one or more instances to an existing event. |
+ | | |
+ | CANCEL | Cancel one or more instances of an existing |
+ | | event. |
+ | | |
+ | REFRESH | A request is sent to an Organizer by an Attendee |
+ | | asking for the latest version of an event to be |
+ | | resent to the requester. |
+ | | |
+ | COUNTER | Counter a REQUEST with an alternative proposal. |
+ | | Sent by an Attendee to the Organizer. |
+ | | |
+ | DECLINECOUNTER | Decline a counter proposal. Sent to an Attendee |
+ | | by the Organizer. |
+ +----------------+--------------------------------------------------+
+
+3.2.1. PUBLISH
+
+ The "PUBLISH" method in a "VEVENT" calendar component is an
+ unsolicited posting of an iCalendar object. Any CU may add published
+ components to their calendar. The "Organizer" MUST be present in a
+ published iCalendar component. "Attendees" MUST NOT be present. Its
+ expected usage is for encapsulating an arbitrary event as an
+ iCalendar object. The "Organizer" may subsequently update (with
+ another "PUBLISH" method), add instances to (with an "ADD" method),
+ or cancel (with a "CANCEL" method) a previously published "VEVENT"
+ calendar component.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+Daboo Standards Track [Page 18]
+
+RFC 5546 iTIP December 2009
+
+
+ +----------------------------------------------+
+ | Constraints for a METHOD:PUBLISH of a VEVENT |
+ +----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST equal PUBLISH. |
+ | | | |
+ | VEVENT | 1+ | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | SEQUENCE | 0 or 1 | MUST be present if value is |
+ | | | greater than 0; MAY be present if |
+ | | | 0. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0 or 1 | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | TENTATIVE/CONFIRMED/CANCELLED. |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+
+
+
+Daboo Standards Track [Page 19]
+
+RFC 5546 iTIP December 2009
+
+
+ | ATTENDEE | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.2. REQUEST
+
+ The "REQUEST" method in a "VEVENT" component provides the following
+ scheduling functions:
+
+ o Invite "Attendees" to an event.
+
+ o Reschedule an existing event.
+
+ 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
+ rescheduling it.
+
+ 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
+ "Attendee" 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
+ "REQUEST" method are the CUs invited to the event, the "Attendees".
+ "Attendees" use the "REPLY" method to convey attendance status to the
+ "Organizer".
+
+
+
+Daboo Standards Track [Page 20]
+
+RFC 5546 iTIP December 2009
+
+
+ The "UID" and "SEQUENCE" properties are used to distinguish the
+ various uses of the "REQUEST" method. If the "UID" property value in
+ the "REQUEST" is not found on the recipient's calendar, then the
+ "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
+ property value is found on the recipient's calendar, then the
+ "REQUEST" is for a rescheduling, an update, or a reconfirmation of
+ the "VEVENT" calendar component.
+
+ For the "REQUEST" method, multiple "VEVENT" components in a single
+ iCalendar object are only permitted for components with the same
+ "UID" property. That is, a series of recurring events may have
+ instance-specific information. In this case, multiple "VEVENT"
+ components are needed to express the entire series.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +----------------------------------------------+
+ | Constraints for a METHOD:REQUEST of a VEVENT |
+ +----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REQUEST. |
+ | | | |
+ | VEVENT | 1+ | All components MUST have the same |
+ | | | UID. |
+ | ATTENDEE | 1+ | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 0 or 1 | MUST be present if value is |
+ | | | greater than 0; MAY be present if |
+ | | | 0. |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+
+
+
+
+
+Daboo Standards Track [Page 21]
+
+RFC 5546 iTIP December 2009
+
+
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | REQUEST-STATUS | 0 | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | TENTATIVE/CONFIRMED. |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.2.1. Rescheduling an Event
+
+ The "REQUEST" method may be used to reschedule an event. A
+ rescheduled event involves a change to the existing event in terms of
+ its time or recurrence intervals and possibly the location or
+ description. If the recipient CUA of a "REQUEST" method finds that
+ the "UID" property value already exists on the calendar but that the
+ "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
+ greater than the value for the existing event, then the "REQUEST"
+ method describes a rescheduling of the event.
+
+
+
+Daboo Standards Track [Page 22]
+
+RFC 5546 iTIP December 2009
+
+
+3.2.2.2. Updating or Reconfirmation of an Event
+
+ 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
+ recurrence intervals, and might not involve a change to the location
+ or description for the event. If the recipient CUA of a "REQUEST"
+ method finds that the "UID" property value already exists on the
+ calendar and that the "SEQUENCE" property value in the "REQUEST" is
+ the same as the value for the existing event, then the "REQUEST"
+ method describes an update of the event details, but not a
+ rescheduling of the event.
+
+ The update "REQUEST" method is the appropriate response to a
+ "REFRESH" method sent from an "Attendee" to the "Organizer" of an
+ event.
+
+ The "Organizer" of an event may also send unsolicited "REQUEST"
+ methods. The unsolicited "REQUEST" methods may be used to update the
+ details of the event without rescheduling it, to update the
+ "PARTSTAT" parameter of "Attendees", or to reconfirm the event.
+
+3.2.2.3. Delegating an Event to Another CU
+
+ Some calendar and scheduling systems allow "Attendees" to delegate
+ their presence at an event to another "Calendar User". iTIP supports
+ this concept using the following workflow. Any "Attendee" may
+ delegate their right to participate in a calendar "VEVENT" to another
+ CU. The implication is that the delegate participates in lieu of the
+ original "Attendee", NOT in addition to the "Attendee". The
+ delegator MUST notify the "Organizer" of this action using the steps
+ outlined below. Implementations may support or restrict delegation
+ as they see fit. For instance, some implementations may restrict a
+ delegate from delegating a "REQUEST" to another CU.
+
+ The "Delegator" of an event forwards the existing "REQUEST" to the
+ "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
+ with the calendar address of the "Delegate". The "Delegator" MUST
+ also send a "REPLY" method to the "Organizer" with the "Delegator's"
+ "ATTENDEE" property "PARTSTAT" parameter value set to "DELEGATED".
+ In addition, the "DELEGATED-TO" parameter MUST be included with the
+ calendar address of the "Delegate". Also, a new "ATTENDEE" property
+ for the "Delegate" MUST be included and must specify the calendar
+ user address set in the "DELEGATED-TO" parameter, as above.
+
+ In response to the request, the "Delegate" MUST send a "REPLY" method
+ to the "Organizer", and optionally to the "Delegator". The "REPLY"
+ method SHOULD include the "ATTENDEE" property with the "DELEGATED-
+ FROM" parameter value of the "Delegator's" calendar address.
+
+
+
+Daboo Standards Track [Page 23]
+
+RFC 5546 iTIP December 2009
+
+
+ The "Delegator" may continue to receive updates to the event even
+ though they will not be attending. This is accomplished by the
+ "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in
+ the "REPLY" to the "Organizer".
+
+3.2.2.4. Changing the Organizer
+
+ The situation may arise where the "Organizer" of a "VEVENT" is no
+ longer able to perform the "Organizer" role and abdicates without
+ passing on the "Organizer" role to someone else. When this occurs,
+ the "Attendees" of the "VEVENT" may use out-of-band mechanisms to
+ communicate the situation and agree upon a new "Organizer". The new
+ "Organizer" should then send out a new "REQUEST" with a modified
+ version of the "VEVENT" in which the "SEQUENCE" number has been
+ incremented and the "ORGANIZER" property has been changed to the new
+ "Organizer".
+
+3.2.2.5. Sending on Behalf of the Organizer
+
+ There are a number of scenarios that support the need for a "Calendar
+ User" to act on behalf of the "Organizer" without explicit role
+ changing. This might be the case if the CU designated as "Organizer"
+ 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 another. Using the "SENT-BY" parameter, a "Calendar User" could
+ send an updated "VEVENT" "REQUEST". In the case where one CU sends
+ on behalf of another CU, the "Attendee" responses are still directed
+ back towards the CU designated as "Organizer".
+
+3.2.2.6. Forwarding to an Uninvited CU
+
+ An "Attendee" invited to a "VEVENT" calendar component may send the
+ "VEVENT" calendar component to another new CU not previously
+ associated with the "VEVENT" calendar component. The current
+ "Attendee" invited to the "VEVENT" calendar component does this by
+ forwarding the original "REQUEST" method to the new CU. The new CU
+ can send a "REPLY" to the "Organizer" of the "VEVENT" calendar
+ component. The reply contains an "ATTENDEE" property for the new CU.
+
+ The "Organizer" ultimately decides whether or not the new CU becomes
+ part of the event and is not obligated to do anything with a "REPLY"
+ from a new (uninvited) CU. If the "Organizer" does not want the new
+ CU to be part of the event, the new "ATTENDEE" property is not added
+ to the "VEVENT" calendar component. The "Organizer" MAY send the CU
+ a "CANCEL" message to indicate that they will not be added to the
+ event. If the "Organizer" decides to add the new CU, the new
+ "ATTENDEE" property is added to the "VEVENT" calendar component.
+ Furthermore, the "Organizer" is free to change any "ATTENDEE"
+
+
+
+Daboo Standards Track [Page 24]
+
+RFC 5546 iTIP December 2009
+
+
+ property parameter from the values supplied by the new CU to
+ something the "Organizer" considers appropriate. The "Organizer"
+ SHOULD send the new CU a "REQUEST" message to inform them that they
+ have been added.
+
+ When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
+ MUST NOT make changes to the original message.
+
+3.2.2.7. Updating Attendee Status
+
+ The "Organizer" of an event may also request updated status from one
+ or more "Attendees". The "Organizer" sends a "REQUEST" method to the
+ "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The
+ "SEQUENCE" property for the event is not changed from its previous
+ value. A recipient will determine that the only change in the
+ "REQUEST" is that their "RSVP" property parameter indicates a request
+ for updated status. The recipient SHOULD respond with a "REPLY"
+ method indicating their current status with respect to the "REQUEST".
+
+3.2.3. REPLY
+
+ The "REPLY" method in a "VEVENT" calendar component is used to
+ respond (e.g., accept or decline) to a "REQUEST" or to reply to a
+ delegation "REQUEST". When used to provide a delegation response,
+ the "Delegator" SHOULD include the calendar address of the "Delegate"
+ on the "DELEGATED-TO" property parameter of the "Delegator's"
+ "ATTENDEE" property. The "Delegate" SHOULD include the calendar
+ address of the "Delegator" on the "DELEGATED-FROM" property parameter
+ of the "Delegate's" "ATTENDEE" property.
+
+ The "REPLY" method is also used when processing of a "REQUEST" fails.
+ Depending on the value of the "REQUEST-STATUS" property, no
+ scheduling action may have been performed.
+
+ The "Organizer" of an event may receive the "REPLY" method from a CU
+ not in the original "REQUEST". For example, a "REPLY" may be
+ received from a "Delegate" to an event. In addition, the "REPLY"
+ method may be received from an unknown CU (a "Party Crasher"). This
+ uninvited "Attendee" may be accepted, or the "Organizer" may cancel
+ the event for the uninvited "Attendee" by sending a "CANCEL" method
+ to the uninvited "Attendee".
+
+ An "Attendee" MAY include a message to the "Organizer" using the
+ "COMMENT" property. For example, if the user indicates tentative
+ acceptance and wants to let the "Organizer" know why, the reason can
+ be expressed in the "COMMENT" property value.
+
+
+
+
+
+Daboo Standards Track [Page 25]
+
+RFC 5546 iTIP December 2009
+
+
+ The "Organizer" may also receive a "REPLY" from one CU on behalf of
+ another. Like the scenario enumerated above for the "Organizer",
+ "Attendees" may have another CU respond on their behalf. This is
+ done using the "SENT-BY" parameter.
+
+ The optional properties listed in the table below (those listed as
+ "0+" or "0 or 1") MUST NOT be changed from those of the original
+ request. If property changes are desired, the "COUNTER" message must
+ be used.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +--------------------------------------------+
+ | Constraints for a METHOD:REPLY of a VEVENT |
+ +--------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REPLY. |
+ | | | |
+ | VEVENT | 1+ | All components MUST have the same |
+ | | | UID. |
+ | ATTENDEE | 1 | MUST be the address of the |
+ | | | Attendee replying. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | UID | 1 | MUST be the UID of the original |
+ | | | REQUEST. |
+ | SEQUENCE | 0 or 1 | If non-zero, MUST be the sequence |
+ | | | number of the original REQUEST. |
+ | | | MAY be present if 0. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DTSTART | 0 or 1 | |
+
+
+
+
+Daboo Standards Track [Page 26]
+
+RFC 5546 iTIP December 2009
+
+
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | REQUEST-STATUS | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | |
+ | SUMMARY | 0 or 1 | |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.4. ADD
+
+ The "ADD" method allows the "Organizer" to add one or more new
+ instances to an existing "VEVENT" using a single iTIP message without
+ having to send the entire "VEVENT" with all the existing instance
+ 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
+ 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
+ updated with the latest version of the "VEVENT". If an "Attendee"
+ implementation does not support the "ADD" method, it should respond
+ with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
+
+
+
+
+Daboo Standards Track [Page 27]
+
+RFC 5546 iTIP December 2009
+
+
+ When handling an "ADD" message, the "Attendee" treats each component
+ in the "ADD" message as if it were referenced via an "RDATE" in the
+ main component.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +------------------------------------------+
+ | Constraints for a METHOD:ADD of a VEVENT |
+ +------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be ADD. |
+ | | | |
+ | VEVENT | 1 | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | MUST be greater than 0. |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | MUST match that of the original |
+ | | | event. |
+ | ATTACH | 0+ | |
+ | ATTENDEE | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | TENTATIVE/CONFIRMED. |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+
+
+
+Daboo Standards Track [Page 28]
+
+RFC 5546 iTIP December 2009
+
+
+ | EXDATE | 0 | |
+ | RECURRENCE-ID | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | RDATE | 0 | |
+ | RRULE | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.5. CANCEL
+
+ The "CANCEL" method in a "VEVENT" calendar component is used to send
+ a cancellation notice of an existing event request to the affected
+ "Attendees". The message is sent by the "Organizer" of the event.
+ For a recurring event, either the whole event or instances of an
+ event may be cancelled. To cancel the complete range of a recurring
+ event, the "UID" property value for the event MUST be specified and a
+ "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In
+ order to cancel an individual instance of the event, the
+ "RECURRENCE-ID" property value for the event MUST be specified in the
+ "CANCEL" method.
+
+ There are two options for canceling a sequence of instances of a
+ recurring "VEVENT" calendar component:
+
+ a. The "RECURRENCE-ID" property for an instance in the sequence MUST
+ be specified with the "RANGE" property parameter value of
+ "THISANDFUTURE" to indicate cancellation of the specified
+ "VEVENT" calendar component and all instances after.
+
+ b. Individual recurrence instances may be cancelled by specifying
+ multiple "VEVENT" components each with a "RECURRENCE-ID" property
+ corresponding to one of the instances to be cancelled.
+
+
+
+
+
+
+Daboo Standards Track [Page 29]
+
+RFC 5546 iTIP December 2009
+
+
+ The "Organizer" MUST send a "CANCEL" message to each "Attendee"
+ affected by the cancellation. This can be done using a single
+ "CANCEL" message for all "Attendees" or by using multiple messages
+ with different subsets of the affected "Attendees" in each.
+
+ When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
+ incremented as described in Section 2.1.4.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +---------------------------------------------+
+ | Constraints for a METHOD:CANCEL of a VEVENT |
+ +---------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be CANCEL. |
+ | | | |
+ | VEVENT | 1+ | All must have the same UID. |
+ | ATTENDEE | 0+ | MUST include some or all |
+ | | | Attendees being removed from the |
+ | | | event. MUST include some or all |
+ | | | Attendees if the entire event is |
+ | | | cancelled. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | |
+ | UID | 1 | MUST be the UID of the original |
+ | | | REQUEST. |
+ | COMMENT | 0+ | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DTSTART | 0 or 1 | |
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+
+
+
+Daboo Standards Track [Page 30]
+
+RFC 5546 iTIP December 2009
+
+
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MUST be set to CANCELLED to |
+ | | | cancel the entire event. If |
+ | | | uninviting specific Attendees, |
+ | | | then MUST NOT be included. |
+ | SUMMARY | 0 or 1 | |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.6. REFRESH
+
+ The "REFRESH" method in a "VEVENT" calendar component is used by
+ "Attendees" of an existing event to request an updated description
+ from the event "Organizer". The "REFRESH" method must specify the
+ "UID" property of the event to update. A recurrence instance of an
+ event may be requested by specifying the "RECURRENCE-ID" property
+ corresponding to the associated event. The "Organizer" responds with
+ the latest description and version of the event.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+Daboo Standards Track [Page 31]
+
+RFC 5546 iTIP December 2009
+
+
+ +----------------------------------------------+
+ | Constraints for a METHOD:REFRESH of a VEVENT |
+ +----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REFRESH. |
+ | | | |
+ | VEVENT | 1 | |
+ | ATTENDEE | 1 | MUST be the address of requester. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | UID | 1 | MUST be the UID associated with |
+ | | | original REQUEST. |
+ | COMMENT | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | ATTACH | 0 | |
+ | CATEGORIES | 0 | |
+ | CLASS | 0 | |
+ | CONTACT | 0 | |
+ | CREATED | 0 | |
+ | DESCRIPTION | 0 | |
+ | DTEND | 0 | |
+ | DTSTART | 0 | |
+ | DURATION | 0 | |
+ | EXDATE | 0 | |
+ | GEO | 0 | |
+ | LAST-MODIFIED | 0 | |
+ | LOCATION | 0 | |
+ | PRIORITY | 0 | |
+ | RDATE | 0 | |
+ | RELATED-TO | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | RESOURCES | 0 | |
+ | RRULE | 0 | |
+ | SEQUENCE | 0 | |
+ | STATUS | 0 | |
+ | SUMMARY | 0 | |
+ | TRANSP | 0 | |
+ | URL | 0 | |
+ | | | |
+
+
+
+
+Daboo Standards Track [Page 32]
+
+RFC 5546 iTIP December 2009
+
+
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.7. COUNTER
+
+ The "COUNTER" method for a "VEVENT" calendar component is used by an
+ "Attendee" of an existing event to submit to the "Organizer" a
+ counter proposal to the event. The "Attendee" sends this message to
+ the "Organizer" of the event.
+
+ The counter proposal is an iCalendar object consisting of a "VEVENT"
+ calendar component that provides the complete description of the
+ alternate event.
+
+ The "Organizer" rejects the counter proposal by sending the
+ "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
+ counter proposal by rescheduling the event as described in
+ Section 3.2.2.1, "Rescheduling an Event". The "Organizer's" CUA
+ SHOULD send a "REQUEST" message to all "Attendees" affected by any
+ change triggered by an accepted "COUNTER".
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +----------------------------------------------+
+ | Constraints for a METHOD:COUNTER of a VEVENT |
+ +----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be COUNTER. |
+ | | | |
+ | VEVENT | 1 | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+
+
+
+
+Daboo Standards Track [Page 33]
+
+RFC 5546 iTIP December 2009
+
+
+ | ORGANIZER | 1 | MUST be the Organizer of the |
+ | | | original event. |
+ | SEQUENCE | 1 | MUST echo the original SEQUENCE |
+ | | | number. MUST be present if |
+ | | | non-zero. MAY be present if |
+ | | | zero. |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | MUST be the UID associated with |
+ | | | the REQUEST being countered. |
+ | ATTACH | 0+ | |
+ | ATTENDEE | 0+ | Can also be used to propose other |
+ | | | Attendees. |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | REQUEST-STATUS | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | Value must be one of |
+ | | | CONFIRMED/TENATIVE/CANCELLED. |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+
+
+
+Daboo Standards Track [Page 34]
+
+RFC 5546 iTIP December 2009
+
+
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.8. DECLINECOUNTER
+
+ The "DECLINECOUNTER" method in a "VEVENT" calendar component is used
+ by the "Organizer" of an event to reject a counter proposal submitted
+ by an "Attendee". The "Organizer" must send the "DECLINECOUNTER"
+ message to the "Attendee" that sent the "COUNTER" method to the
+ "Organizer".
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +-----------------------------------------------------+
+ | Constraints for a METHOD:DECLINECOUNTER of a VEVENT |
+ +-----------------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be DECLINECOUNTER. |
+ | | | |
+ | VEVENT | 1+ | All components MUST have the same |
+ | | | UID. |
+ | ATTENDEE | 1+ | MUST for all Attendees. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | MUST echo the original SEQUENCE |
+ | | | number. |
+ | UID | 1 | MUST echo original UID. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTSTART | 0 or 1 | |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+
+
+
+Daboo Standards Track [Page 35]
+
+RFC 5546 iTIP December 2009
+
+
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | REQUEST-STATUS | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | TENTATIVE/CONFIRMED. |
+ | SUMMARY | 0 or 1 | Can be null. |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VALARM | 0 | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 36]
+
+RFC 5546 iTIP December 2009
+
+
+3.3. Methods for VFREEBUSY Components
+
+ This section defines the property set for the methods that are
+ applicable to the "VFREEBUSY" calendar component. Each of the
+ methods is defined using a restriction table.
+
+ This document only addresses the transfer of busy time information.
+ Applications desiring free time information MUST infer this from
+ available busy time information.
+
+ The "FREEBUSY" property value MAY include a list of values, separated
+ by the COMMA character (US-ASCII decimal 44). Alternately, multiple
+ busy time periods MAY be specified with multiple instances of the
+ "FREEBUSY" property. Both forms MUST be supported by implementations
+ conforming to this document. Duplicate busy time periods SHOULD NOT
+ be specified in an iCalendar object. However, two different busy
+ time periods MAY overlap.
+
+ "FREEBUSY" properties SHOULD be sorted such that their values are in
+ ascending order, based on the start time and then the end time, with
+ the earliest periods first. For example, today's busy time
+ information should appear after yesterday's busy time information.
+ 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
+ boundary.
+
+ The following summarizes the methods that are defined for the
+ "VFREEBUSY" calendar component.
+
+ +---------+-------------------------------------+
+ | Method | Description |
+ +---------+-------------------------------------+
+ | PUBLISH | Publish unsolicited busy time data. |
+ | | |
+ | REQUEST | Request busy time data. |
+ | | |
+ | REPLY | Reply to a busy time request. |
+ +---------+-------------------------------------+
+
+3.3.1. PUBLISH
+
+ The "PUBLISH" method in a "VFREEBUSY" calendar component is used to
+ publish busy time data. The method may be sent from one CU to any
+ other. The purpose of the method is to provide a way to send
+ unsolicited busy time data. That is, the busy time data is not being
+ sent as a "REPLY" to the receipt of a "REQUEST" method.
+
+
+
+
+
+Daboo Standards Track [Page 37]
+
+RFC 5546 iTIP December 2009
+
+
+ The "ORGANIZER" property MUST be specified in the busy time
+ information. The value is the CU address of the originator of the
+ busy time information.
+
+ The busy time information within the iCalendar object MAY be grouped
+ into more than one "VFREEBUSY" calendar component. This capability
+ allows busy time periods to be grouped according to some common
+ periodicity, such as a calendar week, month, or year. In this case,
+ each "VFREEBUSY" calendar component MUST include the "ORGANIZER",
+ "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 covers.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 38]
+
+RFC 5546 iTIP December 2009
+
+
+ +-------------------------------------------------+
+ | Constraints for a METHOD:PUBLISH of a VFREEBUSY |
+ +-------------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be PUBLISH. |
+ | | | |
+ | VFREEBUSY | 1+ | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | DateTime values must be in UTC. |
+ | DTEND | 1 | DateTime values must be in UTC. |
+ | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
+ | | | instances are allowed. Multiple |
+ | | | instances SHOULD be sorted in |
+ | | | ascending order. |
+ | ORGANIZER | 1 | MUST contain the address of |
+ | | | originator of busy time data. |
+ | UID | 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | URL | 0 or 1 | Specifies busy time URL. |
+ | ATTENDEE | 0 | |
+ | DURATION | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTIMEZONE | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 39]
+
+RFC 5546 iTIP December 2009
+
+
+3.3.2. REQUEST
+
+ The "REQUEST" method in a "VFREEBUSY" calendar component is used to
+ ask a "Calendar User" for their busy time information. The request
+ may be for a busy time information bounded by a specific date and
+ time interval.
+
+ This message only permits requests for busy time information. The
+ message is sent from a "Calendar User" requesting the busy time
+ information of one or more intended recipients.
+
+ If the originator of the "REQUEST" method is not authorized to make a
+ busy time request on the recipient's calendar system, then an
+ exception message SHOULD be returned in a "REPLY" method, but no busy
+ time data need be returned.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 40]
+
+RFC 5546 iTIP December 2009
+
+
+ +-------------------------------------------------+
+ | Constraints for a METHOD:REQUEST of a VFREEBUSY |
+ +-------------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REQUEST. |
+ | | | |
+ | VFREEBUSY | 1 | |
+ | ATTENDEE | 1+ | Contains the calendar user |
+ | | | addresses of the "Calendar Users" |
+ | | | whose freebusy is being |
+ | | | requested. |
+ | DTEND | 1 | DateTime values must be in UTC. |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | DateTime values must be in UTC. |
+ | ORGANIZER | 1 | MUST be the request originator's |
+ | | | address. |
+ | UID | 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | FREEBUSY | 0 | |
+ | DURATION | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | URL | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTIMEZONE | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 41]
+
+RFC 5546 iTIP December 2009
+
+
+3.3.3. REPLY
+
+ The "REPLY" method in a "VFREEBUSY" calendar component is used to
+ respond to a busy time request. The method is sent by the recipient
+ of a busy time request to the originator of the request.
+
+ The "REPLY" method may also be used to respond to an unsuccessful
+ "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy
+ time information may be returned.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 42]
+
+RFC 5546 iTIP December 2009
+
+
+ +-----------------------------------------------+
+ | Constraints for a METHOD:REPLY of a VFREEBUSY |
+ +-----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REPLY. |
+ | | | |
+ | VFREEBUSY | 1 | |
+ | ATTENDEE | 1 | MUST be the address of the |
+ | | | Attendee replying. |
+ | DTSTAMP | 1 | |
+ | DTEND | 1 | DateTime values must be in UTC. |
+ | DTSTART | 1 | DateTime values must be in UTC. |
+ | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
+ | | | instances are allowed. Multiple |
+ | | | instances SHOULD be sorted in |
+ | | | ascending order. |
+ | ORGANIZER | 1 | MUST be the request originator's |
+ | | | address. |
+ | UID | 1 | MUST be the UID of the original |
+ | | | REQUEST. |
+ | COMMENT | 0+ | |
+ | CONTACT | 0 or 1 | |
+ | REQUEST-STATUS | 0+ | |
+ | URL | 0 or 1 | Specifies busy time URL. |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | DURATION | 0 | |
+ | SEQUENCE | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTIMEZONE | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+
+
+
+Daboo Standards Track [Page 43]
+
+RFC 5546 iTIP December 2009
+
+
+3.4. Methods for VTODO Components
+
+ This section defines the property set for the methods that are
+ applicable to the "VTODO" calendar component. Each of the methods is
+ defined using a restriction table that specifies the property
+ constraints that define the particular method.
+
+ The following summarizes the methods that are defined for the "VTODO"
+ calendar component.
+
+ +----------------+--------------------------------------------------+
+ | Method | Description |
+ +----------------+--------------------------------------------------+
+ | PUBLISH | Post notification of a VTODO. Used primarily as |
+ | | a method of advertising the existence of a |
+ | | VTODO. |
+ | | |
+ | REQUEST | Assign a VTODO. This is an explicit assignment |
+ | | to one or more Calendar Users. The REQUEST |
+ | | method is also used to update or change an |
+ | | existing VTODO. Clients that cannot handle |
+ | | REQUEST MAY degrade the method to treat it as a |
+ | | PUBLISH. |
+ | | |
+ | REPLY | Reply to a VTODO request. Attendees MAY set |
+ | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, |
+ | | DELEGATED, PARTIAL, and COMPLETED. |
+ | | |
+ | ADD | Add one or more instances to an existing to-do. |
+ | | |
+ | CANCEL | Cancel one or more instances of an existing |
+ | | to-do. |
+ | | |
+ | REFRESH | A request sent to a VTODO Organizer asking for |
+ | | the latest version of a VTODO. |
+ | | |
+ | COUNTER | Counter a REQUEST with an alternative proposal. |
+ | | |
+ | DECLINECOUNTER | Decline a counter proposal by an Attendee. |
+ +----------------+--------------------------------------------------+
+
+3.4.1. PUBLISH
+
+ The "PUBLISH" method in a "VTODO" calendar component has no
+ associated response. It is simply a posting of an iCalendar object
+ that may be added to a calendar. It MUST have an "Organizer". It
+ MUST NOT have "Attendees". Its expected usage is for encapsulating
+ an arbitrary "VTODO" calendar component as an iCalendar object. The
+
+
+
+Daboo Standards Track [Page 44]
+
+RFC 5546 iTIP December 2009
+
+
+ "Organizer" MAY subsequently update (with another "PUBLISH" method),
+ add instances to (with an "ADD" method), or cancel (with a "CANCEL"
+ method) a previously published "VTODO" calendar component.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +---------------------------------------------+
+ | Constraints for a METHOD:PUBLISH of a VTODO |
+ +---------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be PUBLISH. |
+ | | | |
+ | VTODO | 1+ | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | PRIORITY | 1 | |
+ | SEQUENCE | 0 or 1 | MUST be present if value is |
+ | | | greater than 0; MAY be present if |
+ | | | 0. |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+
+
+
+Daboo Standards Track [Page 45]
+
+RFC 5546 iTIP December 2009
+
+
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | COMPLETED/NEEDS-ACTION/ |
+ | | | IN-PROCESS/CANCELLED. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | ATTENDEE | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.2. REQUEST
+
+ The "REQUEST" method in a "VTODO" calendar component provides the
+ following scheduling functions:
+
+ 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 Update the completion status of "Attendees" of an existing to-do,
+ without rescheduling it.
+
+ 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
+ component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property
+ value sequences.
+
+
+
+Daboo Standards Track [Page 46]
+
+RFC 5546 iTIP December 2009
+
+
+ Typically, the originator of a "REQUEST" is the "Organizer" of the
+ to-do, and the recipient of a "REQUEST" is the "Calendar User"
+ assigned the to-do. The "Attendee" uses the "REPLY" method to convey
+ their acceptance and completion status to the "Organizer" of the
+ "REQUEST".
+
+ The "UID", "SEQUENCE", and "DTSTAMP" properties are used to
+ distinguish the various uses of the "REQUEST" method. If the "UID"
+ property value in the "REQUEST" is not found on the recipient's
+ calendar, then the "REQUEST" is for a new to-do. If the "UID"
+ property value is found on the recipient's calendar, then the
+ "REQUEST" is a rescheduling, an update, or a reconfirmation of the
+ "VTODO" calendar object.
+
+ If the "Organizer" of the "REQUEST" method is not authorized to make
+ a to-do request on the "Attendee's" calendar system, then an
+ exception is returned in the "REQUEST-STATUS" property of a
+ subsequent "REPLY" method, but no scheduling action is performed.
+
+ For the "REQUEST" method, multiple "VTODO" components in a single
+ iCalendar object are only permitted for components with the same
+ "UID" property. That is, a series of recurring events may have
+ instance-specific information. In this case, multiple "VTODO"
+ components are needed to express the entire series.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +---------------------------------------------+
+ | Constraints for a METHOD:REQUEST of a VTODO |
+ +---------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REQUEST. |
+ | | | |
+ | VTODO | 1+ | All components must have the same |
+ | | | UID. |
+ | ATTENDEE | 1+ | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | PRIORITY | 1 | |
+ | SEQUENCE | 0 or 1 | MUST be present if value is |
+ | | | greater than 0; MAY be present if |
+ | | | 0. |
+ | SUMMARY | 1 | Can be null. |
+
+
+
+Daboo Standards Track [Page 47]
+
+RFC 5546 iTIP December 2009
+
+
+ | UID | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | COMPLETED/NEEDS-ACTION/ |
+ | | | IN-PROCESS. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+Daboo Standards Track [Page 48]
+
+RFC 5546 iTIP December 2009
+
+
+3.4.2.1. REQUEST for Rescheduling a VTODO
+
+ The "REQUEST" method may be used to reschedule a "VTODO" calendar
+ component.
+
+ Rescheduling a "VTODO" calendar component involves a change to the
+ existing "VTODO" calendar component in terms of its start or due
+ time, recurrence intervals, and possibly the description. If the
+ recipient CUA of a "REQUEST" method finds that the "UID" property
+ value already exists on the calendar but that the "SEQUENCE" property
+ value in the "REQUEST" is greater than the value for the existing
+ "VTODO", then the "REQUEST" method describes a rescheduling of the
+ "VTODO" calendar component.
+
+3.4.2.2. REQUEST for Update or Reconfirmation of a VTODO
+
+ The "REQUEST" method may be used to update or reconfirm a "VTODO"
+ calendar component. Reconfirmation is merely an update of "Attendee"
+ completion status or overall "VTODO" calendar component status.
+
+ An update to an existing "VTODO" calendar component does not involve
+ changes to the start or due time, recurrence intervals, or
+ (generally) the description for the "VTODO" calendar component. If
+ the recipient CUA of a "REQUEST" method finds that the "UID" property
+ value already exists on the calendar and that the "SEQUENCE" property
+ value in the "REQUEST" is the same as the value for the existing
+ event, then the "REQUEST" method describes an update of the "VTODO"
+ calendar component details, but not a rescheduling of the "VTODO"
+ calendar component.
+
+ The update "REQUEST" is the appropriate response to a "REFRESH"
+ method sent from an "Attendee" to the "Organizer" of a "VTODO"
+ calendar component.
+
+ Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a
+ "VTODO" calendar component. The unsolicited "REQUEST" methods are
+ used to update the details of the "VTODO" (without rescheduling it or
+ updating the completion status of "Attendees") or the "VTODO"
+ calendar component itself (i.e., reconfirm the "VTODO").
+
+3.4.2.3. REQUEST for Delegating a VTODO
+
+ The "REQUEST" method is also used to delegate or reassign ownership
+ of a "VTODO" calendar component to another "Calendar User". For
+ example, it may be used to delegate an "Attendee's" role (i.e.,
+ "chair" or "participant") for a "VTODO" calendar component. The
+ "REQUEST" method is sent by one of the "Attendees" of an existing
+ "VTODO" calendar component to some other individual.
+
+
+
+Daboo Standards Track [Page 49]
+
+RFC 5546 iTIP December 2009
+
+
+ For the purposes of this description, the "Attendee" delegating the
+ "VTODO" calendar component is referred to as the "Delegator". The
+ "Attendee" receiving the delegation request is referred to as the
+ "Delegate".
+
+ The "Delegator" of a "VTODO" calendar component MUST forward the
+ existing "REQUEST" method for a "VTODO" calendar component to the
+ "Delegate". The "VTODO" calendar component description MUST include
+ the "Delegator's" up-to-date "VTODO" calendar component definition.
+ The "REQUEST" method MUST also include an "ATTENDEE" property with
+ the calendar address of the "Delegate". The "Delegator" MUST also
+ send a "REPLY" method back to the "Organizer" with the "Delegator's"
+ "Attendee" property "PARTSTAT" parameter value set to "DELEGATED".
+ In addition, the "DELEGATED-TO" parameter MUST be included with the
+ calendar address of the "Delegate". A response to the delegation
+ "REQUEST" is sent from the "Delegate" to the "Organizer", and
+ optionally to the "Delegator". The "REPLY" method from the
+ "Delegate" SHOULD include the "ATTENDEE" property with their calendar
+ address and the "DELEGATED-FROM" parameter with the value of the
+ "Delegator's" calendar address.
+
+ The delegation "REQUEST" method MUST assign a value for the "RSVP"
+ property parameter associated with the "Delegator's" "Attendee"
+ property to that of the "Delegate's" "ATTENDEE" property. For
+ example, if the "Delegator's" "ATTENDEE" property specifies
+ "RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify
+ "RSVP=TRUE".
+
+3.4.2.4. REQUEST Forwarded to an Uninvited Calendar User
+
+ An "Attendee" assigned a "VTODO" calendar component may send the
+ "VTODO" calendar component to another new CU not previously
+ associated with the "VTODO" calendar component. The current
+ "Attendee" assigned the "VTODO" calendar component does this by
+ forwarding the original "REQUEST" method to the new CU. The new CU
+ can send a "REPLY" to the "Organizer" of the "VTODO" calendar
+ component. The reply contains an "ATTENDEE" property for the new CU.
+
+ The "Organizer" ultimately decides whether or not the new CU becomes
+ part of the to-do and is not obligated to do anything with a "REPLY"
+ from a new (uninvited) CU. If the "Organizer" does not want the new
+ CU to be part of the to-do, the new "ATTENDEE" property is not added
+ to the "VTODO" calendar component. The "Organizer" MAY send the CU a
+ "CANCEL" message to indicate that they will not be added to the to-
+ do. If the "Organizer" decides to add the new CU, the new "ATTENDEE"
+ property is added to the "VTODO" calendar component. Furthermore,
+ the "Organizer" is free to change any "ATTENDEE" property parameter
+ from the values supplied by the new CU to something the "Organizer"
+
+
+
+Daboo Standards Track [Page 50]
+
+RFC 5546 iTIP December 2009
+
+
+ considers appropriate. The "Organizer" SHOULD send the new
+ "Attendee" a "REQUEST" message to inform them that they have been
+ added.
+
+ When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
+ MUST NOT make changes to the original message.
+
+3.4.2.5. REQUEST Updated Attendee Status
+
+ An "Organizer" of a "VTODO" may request an updated status from one or
+ more "Attendees". The "Organizer" sends a "REQUEST" method to the
+ "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The
+ "SEQUENCE" property for the "VTODO" is not changed from its previous
+ value. A recipient determines that the only change in the "REQUEST"
+ is that their "RSVP" property parameter indicates a request for an
+ updated status. The recipient SHOULD respond with a "REPLY" method
+ indicating their current status with respect to the "REQUEST".
+
+3.4.3. REPLY
+
+ The "REPLY" method in a "VTODO" calendar component is used to respond
+ (e.g., accept or decline) to a request or to reply to a delegation
+ request. It is also used by an "Attendee" to update their completion
+ status. When used to provide a delegation response, the "Delegator"
+ MUST include the calendar address of the "Delegate" in the
+ "DELEGATED-TO" parameter of the "Delegator's" "ATTENDEE" property.
+ The "Delegate" MUST include the calendar address of the "Delegator"
+ on the "DELEGATED-FROM" parameter of the "Delegate's" "ATTENDEE"
+ property.
+
+ The "REPLY" method MAY also be used to respond to an unsuccessful
+ "VTODO" calendar component "REQUEST" method. Depending on the
+ "REQUEST-STATUS" value, no scheduling action may have been performed.
+
+ The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY"
+ method from a "Calendar User" not in the original "REQUEST". For
+ example, a "REPLY" method MAY be received from a "Delegate" of a
+ "VTODO" calendar component. In addition, the "REPLY" method MAY be
+ received from an unknown "Calendar User" who has been forwarded the
+ "REQUEST" by an original "Attendee" of the "VTODO" calendar
+ component. This uninvited "Attendee" MAY be accepted or the
+ "Organizer" MAY cancel the "VTODO" calendar component for the
+ uninvited "Attendee" by sending them a "CANCEL" method.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+Daboo Standards Track [Page 51]
+
+RFC 5546 iTIP December 2009
+
+
+ +-------------------------------------------+
+ | Constraints for a METHOD:REPLY of a VTODO |
+ +-------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REPLY. |
+ | | | |
+ | VTODO | 1+ | All components MUST have the same |
+ | | | UID. |
+ | ATTENDEE | 1 | MUST be the address of the |
+ | | | Attendee replying. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | REQUEST-STATUS | 0+ | |
+ | UID | 1 | MUST be the UID of the original |
+ | | | REQUEST. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTSTART | 0 or 1 | |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | SEQUENCE | 0 or 1 | MUST be the sequence number of |
+ | | | the original REQUEST if greater |
+ | | | than 0. MAY be present if 0. |
+
+
+
+Daboo Standards Track [Page 52]
+
+RFC 5546 iTIP December 2009
+
+
+ | STATUS | 0 or 1 | |
+ | SUMMARY | 0 or 1 | Can be null. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.4. ADD
+
+ The "ADD" method allows the "Organizer" to add one or more new
+ instances to an existing "VTODO" using a single iTIP message without
+ having to send the entire "VTODO" with all the existing instance
+ 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
+ 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
+ updated with the latest version of the "VTODO". If an "Attendee"
+ implementation does not support the "ADD" method, it should respond
+ with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
+
+ When handling an "ADD" message, the "Attendee" treats each component
+ in the "ADD" message as if it were referenced via an "RDATE" in the
+ main component.
+
+ The "SEQUENCE" property value is incremented since the sequence of
+ to-dos has changed.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 53]
+
+RFC 5546 iTIP December 2009
+
+
+ +-----------------------------------------+
+ | Constraints for a METHOD:ADD of a VTODO |
+ +-----------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be ADD. |
+ | | | |
+ | VTODO | 1 | |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | PRIORITY | 1 | |
+ | SEQUENCE | 1 | MUST be greater than 0. |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | MUST match that of the original |
+ | | | to-do. |
+ | ATTACH | 0+ | |
+ | ATTENDEE | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTSTART | 0 or 1 | |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | COMPLETED/NEEDS-ACTION/ |
+ | | | IN-PROCESS. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | EXDATE | 0 | |
+ | RECURRENCE-ID | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | RDATE | 0 | |
+ | RRULE | 0 | |
+
+
+
+Daboo Standards Track [Page 54]
+
+RFC 5546 iTIP December 2009
+
+
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.5. CANCEL
+
+ The "CANCEL" method in a "VTODO" calendar component is used to send a
+ cancellation notice of an existing "VTODO" calendar request to the
+ affected "Attendees". The message is sent by the "Organizer" of a
+ "VTODO" calendar component to the "Attendees" of the "VTODO" calendar
+ component. For a recurring "VTODO" calendar component, either the
+ whole "VTODO" calendar component or instances of a "VTODO" calendar
+ component may be cancelled. To cancel the complete range of a
+ recurring "VTODO" calendar component, the "UID" property value for
+ the "VTODO" calendar component MUST be specified and a "RECURRENCE-
+ ID" MUST NOT be specified in the "CANCEL" method. In order to cancel
+ an individual instance of a recurring "VTODO" calendar component, the
+ "RECURRENCE-ID" property value for the "VTODO" calendar component
+ MUST be specified in the "CANCEL" method.
+
+ There are two options for canceling a sequence of instances of a
+ recurring "VTODO" calendar component:
+
+ a. The "RECURRENCE-ID" property for an instance in the sequence MUST
+ be specified with the "RANGE" property parameter value of
+ "THISANDFUTURE" to indicate cancellation of the specified "VTODO"
+ calendar component and all instances after.
+
+ b. Individual recurrence instances may be cancelled by specifying
+ 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"
+ affected by the cancellation. This can be done by using either a
+ single "CANCEL" message for all "Attendees" or multiple messages with
+ different subsets of the affected "Attendees" in each.
+
+
+
+Daboo Standards Track [Page 55]
+
+RFC 5546 iTIP December 2009
+
+
+ When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
+ incremented as described in Section 2.1.4.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +--------------------------------------------+
+ | Constraints for a METHOD:CANCEL of a VTODO |
+ +--------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be CANCEL. |
+ | | | |
+ | VTODO | 1+ | |
+ | ATTENDEE | 0+ | MUST include some or all |
+ | | | Attendees being removed from the |
+ | | | to-do. MUST include some or all |
+ | | | Attendees if the entire to-do is |
+ | | | cancelled. |
+ | UID | 1 | MUST echo original UID. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTSTART | 0 or 1 | |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | RDATE | 0+ | |
+
+
+
+
+
+
+
+Daboo Standards Track [Page 56]
+
+RFC 5546 iTIP December 2009
+
+
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | STATUS | 0 or 1 | MUST be set to CANCELLED to |
+ | | | cancel the entire VTODO. If |
+ | | | removing specific Attendees, then |
+ | | | MUST NOT be included. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.6. REFRESH
+
+ The "REFRESH" method in a "VTODO" calendar component is used by
+ "Attendees" of an existing "VTODO" calendar component to request an
+ updated description from the "Organizer" of the "VTODO" calendar
+ component. The "Organizer" of the "VTODO" calendar component MAY use
+ this method to request an updated status from the "Attendees". The
+ "REFRESH" method MUST specify the "UID" property corresponding to the
+ "VTODO" calendar component needing update.
+
+ A refresh of a recurrence instance of a "VTODO" calendar component
+ may be requested by specifying the "RECURRENCE-ID" property
+ corresponding to the associated "VTODO" calendar component. The
+ "Organizer" responds with the latest description and rendition of the
+ "VTODO" calendar component. In most cases, this will be a "REQUEST"
+ unless the "VTODO" has been cancelled, in which case the "Organizer"
+ MUST send a "CANCEL". This method is intended to facilitate machine
+ processing of requests for updates to a "VTODO" calendar component.
+
+
+
+Daboo Standards Track [Page 57]
+
+RFC 5546 iTIP December 2009
+
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +---------------------------------------------+
+ | Constraints for a METHOD:REFRESH of a VTODO |
+ +---------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REFRESH. |
+ | | | |
+ | VTODO | 1 | |
+ | ATTENDEE | 1 | |
+ | DTSTAMP | 1 | |
+ | UID | 1 | MUST echo original UID. |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | ATTACH | 0 | |
+ | CATEGORIES | 0 | |
+ | CLASS | 0 | |
+ | COMMENT | 0 | |
+ | COMPLETED | 0 | |
+ | CONTACT | 0 | |
+ | CREATED | 0 | |
+ | DESCRIPTION | 0 | |
+ | DTSTART | 0 | |
+ | DUE | 0 | |
+ | DURATION | 0 | |
+ | EXDATE | 0 | |
+ | GEO | 0 | |
+ | LAST-MODIFIED | 0 | |
+ | LOCATION | 0 | |
+ | ORGANIZER | 0 | |
+ | PERCENT-COMPLETE | 0 | |
+ | PRIORITY | 0 | |
+ | RDATE | 0 | |
+ | RELATED-TO | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | RESOURCES | 0 | |
+ | RRULE | 0 | |
+ | SEQUENCE | 0 | |
+ | STATUS | 0 | |
+ | URL | 0 | |
+
+
+
+Daboo Standards Track [Page 58]
+
+RFC 5546 iTIP December 2009
+
+
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.7. COUNTER
+
+ The "COUNTER" method in a "VTODO" calendar component is used by an
+ "Attendee" of an existing "VTODO" calendar component to submit to the
+ "Organizer" a counter proposal for the "VTODO" calendar component.
+
+ The counter proposal is an iCalendar object consisting of a "VTODO"
+ calendar component that provides the complete description of the
+ alternate "VTODO" calendar component.
+
+ The "Organizer" rejects the counter proposal by sending the
+ "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
+ counter proposal by rescheduling the to-do as described in
+ Section 3.4.2.1, "REQUEST for Rescheduling a To-Do". The
+ "Organizer's" CUA SHOULD send a "REQUEST" message to all "Attendees"
+ affected by any change triggered by an accepted "COUNTER".
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +---------------------------------------------+
+ | Constraints for a METHOD:COUNTER of a VTODO |
+ +---------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be COUNTER. |
+ | | | |
+ | VTODO | 1 | |
+ | ATTENDEE | 1+ | |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | PRIORITY | 1 | |
+ | SUMMARY | 1 | Can be null. |
+
+
+
+Daboo Standards Track [Page 59]
+
+RFC 5546 iTIP December 2009
+
+
+ | UID | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTSTART | 0 or 1 | |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | REQUEST-STATUS | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE |
+ | | | number. MUST be present if |
+ | | | non-zero. MAY be present if |
+ | | | zero. |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | COMPLETED/NEEDS-ACTION/ |
+ | | | IN-PROCESS/CANCELLED. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+
+
+
+
+Daboo Standards Track [Page 60]
+
+RFC 5546 iTIP December 2009
+
+
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.8. DECLINECOUNTER
+
+ The "DECLINECOUNTER" method in a "VTODO" calendar component is used
+ by an "Organizer" of the "VTODO" calendar component to reject a
+ counter proposal offered by one of the "Attendees". The "Organizer"
+ sends the message to the "Attendee" that sent the "COUNTER" method to
+ the "Organizer".
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +----------------------------------------------------+
+ | Constraints for a METHOD:DECLINECOUNTER of a VTODO |
+ +----------------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be DECLINECOUNTER. |
+ | | | |
+ | VTODO | 1 | |
+ | ATTENDEE | 1+ | MUST for all ATTENDEEs. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | MUST echo the original SEQUENCE |
+ | | | number. |
+ | UID | 1 | MUST echo original UID. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTSTART | 0 or 1 | |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+
+
+
+Daboo Standards Track [Page 61]
+
+RFC 5546 iTIP December 2009
+
+
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | REQUEST-STATUS | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | COMPLETED/NEEDS-ACTION/ |
+ | | | IN-PROCESS. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.5. Methods for VJOURNAL Components
+
+ This section defines the property set for the methods that are
+ applicable to the "VJOURNAL" calendar component.
+
+ The following summarizes the methods that are defined for the
+ "VJOURNAL" calendar component.
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 62]
+
+RFC 5546 iTIP December 2009
+
+
+ +---------+---------------------------------------------------------+
+ | Method | Description |
+ +---------+---------------------------------------------------------+
+ | PUBLISH | Post a journal entry. Used primarily as a method of |
+ | | advertising the existence of a journal entry. |
+ | | |
+ | ADD | Add one or more instances to an existing journal entry. |
+ | | |
+ | CANCEL | Cancel one or more instances of an existing journal |
+ | | entry. |
+ +---------+---------------------------------------------------------+
+
+3.5.1. PUBLISH
+
+ The "PUBLISH" method in a "VJOURNAL" calendar component has no
+ associated response. It is simply a posting of an iCalendar object
+ that may be added to a calendar. It MUST have an "Organizer". It
+ MUST NOT have "Attendees". The expected usage is for encapsulating
+ an arbitrary journal entry as an iCalendar object. The "Organizer"
+ MAY subsequently update (with another "PUBLISH" method) or cancel
+ (with a "CANCEL" method) a previously published journal entry.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +------------------------------------------------+
+ | Constraints for a METHOD:PUBLISH of a VJOURNAL |
+ +------------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be PUBLISH. |
+ | | | |
+ | VJOURNAL | 1+ | |
+ | DESCRIPTION | 1 | Can be null. |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | UID | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | EXDATE | 0+ | |
+ | LAST-MODIFIED | 0 or 1 | |
+
+
+
+Daboo Standards Track [Page 63]
+
+RFC 5546 iTIP December 2009
+
+
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | RRULE | 0 or 1 | |
+ | SEQUENCE | 0 or 1 | MUST be present if non-zero. MAY |
+ | | | be present if zero. |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | DRAFT/FINAL/CANCELLED. |
+ | SUMMARY | 0 or 1 | Can be null. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | ATTENDEE | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.5.2. ADD
+
+ The "ADD" method allows the "Organizer" to add one or more new
+ instances to an existing "VJOURNAL" using a single iTIP message
+ without having to send the entire "VJOURNAL" with all the existing
+ instance data, as it would have to do if the "REQUEST" method were
+ used.
+
+ 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,
+ then the recipient MAY treat the "ADD" as a "PUBLISH".
+
+ When handling an "ADD" message, the "Attendee" treats each component
+ in the "ADD" message as if it were referenced via an "RDATE" in the
+ main component. There is no response to the "Organizer".
+
+
+
+Daboo Standards Track [Page 64]
+
+RFC 5546 iTIP December 2009
+
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +--------------------------------------------+
+ | Constraints for a METHOD:ADD of a VJOURNAL |
+ +--------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be ADD. |
+ | | | |
+ | VJOURNAL | 1 | |
+ | DESCRIPTION | 1 | Can be null. |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | MUST be greater than 0. |
+ | UID | 1 | MUST match that of the original |
+ | | | journal. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | RELATED-TO | 0+ | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | DRAFT/FINAL/CANCELLED. |
+ | SUMMARY | 0 or 1 | Can be null. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | ATTENDEE | 0 | |
+ | EXDATE | 0 | |
+ | RECURRENCE-ID | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | RDATE | 0 | |
+ | RRULE | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+
+
+
+Daboo Standards Track [Page 65]
+
+RFC 5546 iTIP December 2009
+
+
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.5.3. CANCEL
+
+ The "CANCEL" method in a "VJOURNAL" calendar component is used to
+ send a cancellation notice of an existing journal entry. The message
+ is sent by the "Organizer" of a journal entry. For a recurring
+ journal entry, either the whole journal entry or instances of a
+ journal entry may be cancelled. To cancel the complete range of a
+ recurring journal entry, the "UID" property value for the journal
+ entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be
+ specified in the "CANCEL" method. In order to cancel an individual
+ instance of the journal entry, the "RECURRENCE-ID" property value for
+ the journal entry MUST be specified in the "CANCEL" method.
+
+ There are two options for canceling a sequence of instances of a
+ recurring "VJOURNAL" calendar component:
+
+ a. The "RECURRENCE-ID" property for an instance in the sequence MUST
+ be specified with the "RANGE" property parameter value of
+ "THISANDFUTURE" to indicate cancellation of the specified
+ "VJOURNAL" calendar component and all instances after.
+
+ b. Individual recurrence instances may be cancelled by specifying
+ 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
+ incremented as described in Section 2.1.4.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 66]
+
+RFC 5546 iTIP December 2009
+
+
+ +-----------------------------------------------+
+ | Constraints for a METHOD:CANCEL of a VJOURNAL |
+ +-----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be CANCEL. |
+ | | | |
+ | VJOURNAL | 1+ | All MUST have the same UID. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | |
+ | UID | 1 | MUST be the UID of the original |
+ | | | REQUEST. |
+ | ATTACH | 0+ | |
+ | ATTENDEE | 0 | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTSTART | 0 or 1 | |
+ | EXDATE | 0+ | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be present; MUST be CANCELLED |
+ | | | if present. |
+ | SUMMARY | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+
+
+
+Daboo Standards Track [Page 67]
+
+RFC 5546 iTIP December 2009
+
+
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.6. Status Replies
+
+ The "REQUEST-STATUS" property is used to convey status information
+ about a "REPLY", "COUNTER", or "DECLINECOUNTER" iTIP message. The
+ codes listed in the table below SHOULD be used. If the "REQUEST-
+ STATUS" property is not present in one of these iTIP messages, then a
+ status code of "2.0" (success) MUST be assumed.
+
+ This specification adds a new IANA registry for "REQUEST-STATUS"
+ property values, as defined in Section 7, which includes a new
+ registration template for defining the specific components of the
+ "REQUEST-STATUS" property value. Additional codes MAY be used,
+ 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
+ be returned in iCalendar components in the appropriate iTIP messages.
+ When multiple "REQUEST-STATUS" properties are present, the following
+ restrictions apply:
+
+ 1. Within any one component, the "top-level" numeric value of the
+ "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 and 5.xx codes within a single component.
+
+ 2. Across all components in the iTIP message, the following applies:
+
+ 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"
+ MUST NOT be present in the other components if a 5.xx code is
+ not appropriate for those components.
+
+ B. Otherwise, if any one component would have a 3.xx code, then
+ either all components MUST have a code in that range or
+ "REQUEST-STATUS" MUST NOT be present in the other 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,
+ provided that each component follows the restriction in (1)
+ above.
+
+
+
+Daboo Standards Track [Page 68]
+
+RFC 5546 iTIP December 2009
+
+
+ The following "REQUEST-STATUS" codes are defined (any "Offending
+ Data" MAY be specified in the "REQUEST-STATUS" value as the extdata
+ field):
+
+3.6.1. Status Code 2.0
+
+ Status Code: 2.0
+
+ Status Description: Success.
+
+ Status Exception Data: None.
+
+ Description: iTIP operation succeeded.
+
+3.6.2. Status Code 2.1
+
+ Status Code: 2.1
+
+ Status Description: Success, but fallback taken on one or more
+ property values.
+
+ Status Exception Data: Property name and value MAY be specified.
+
+ Description: iTIP operation succeeded with fallback on one or more
+ property values.
+
+3.6.3. Status Code 2.2
+
+ Status Code: 2.2
+
+ Status Description: Success; invalid property ignored.
+
+ Status Exception Data: Property name MAY be specified.
+
+ Description: iTIP operation succeeded but a property was ignored.
+
+3.6.4. Status Code 2.3
+
+ Status Code: 2.3
+
+ Status Description: Success; invalid property parameter ignored.
+
+ Status Exception Data: Property parameter name and value MAY be
+ specified.
+
+ Description: iTIP operation succeeded but a property parameter was
+ ignored because it was invalid.
+
+
+
+
+Daboo Standards Track [Page 69]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.5. Status Code 2.4
+
+ Status Code: 2.4
+
+ Status Description: Success; unknown, non-standard property ignored.
+
+ Status Exception Data: Non-standard property name MAY be specified.
+
+ Description: iTIP operation succeeded but a property parameter was
+ ignored because it was unknown.
+
+3.6.6. Status Code 2.5
+
+ Status Code: 2.5
+
+ Status Description: Success; unknown, non-standard property value
+ ignored.
+
+ Status Exception Data: Property and non-standard value MAY be
+ specified.
+
+ Description: iTIP operation succeeded but a property was ignored
+ because its value was unknown.
+
+3.6.7. Status Code 2.6
+
+ Status Code: 2.6
+
+ Status Description: Success; invalid calendar component ignored.
+
+ Status Exception Data: Calendar component sentinel (e.g., BEGIN:
+ ALARM) MAY be specified.
+
+ Description: iTIP operation succeeded but a component was ignored
+ because it was invalid.
+
+3.6.8. Status Code 2.7
+
+ Status Code: 2.7
+
+ Status Description: Success; request forwarded to Calendar User.
+
+ Status Exception Data: Original and forwarded calendar user
+ addresses MAY be specified.
+
+ Description: iTIP operation succeeded, and the request was forwarded
+ to another Calendar User.
+
+
+
+
+Daboo Standards Track [Page 70]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.9. Status Code 2.8
+
+ Status Code: 2.8
+
+ Status Description: Success; repeating event ignored. Scheduled as
+ a single component.
+
+ Status Exception Data: RRULE or RDATE property name and value MAY be
+ specified.
+
+ Description: iTIP operation succeeded but a repeating event was
+ truncated to a single instance.
+
+3.6.10. Status Code 2.9
+
+ Status Code: 2.9
+
+ Status Description: Success; truncated end date time to date
+ boundary.
+
+ Status Exception Data: DTEND property value MAY be specified.
+
+ Description: iTIP operation succeeded but the end time was truncated
+ to a date boundary.
+
+3.6.11. Status Code 2.10
+
+ Status Code: 2.10
+
+ Status Description: Success; repeating VTODO ignored. Scheduled as
+ a single VTODO.
+
+ Status Exception Data: RRULE or RDATE property name and value MAY be
+ specified.
+
+ Description: iTIP operation succeeded but a repeating to-do was
+ truncated to a single instance.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 71]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.12. Status Code 2.11
+
+ Status Code: 2.11
+
+ Status Description: Success; unbounded RRULE clipped at some finite
+ number of instances.
+
+ Status Exception Data: RRULE property name and value MAY be
+ specified. Number of instances MAY also be specified.
+
+ Description: iTIP operation succeeded but an unbounded repeating
+ object was clipped to a finite number of instances.
+
+3.6.13. Status Code 3.0
+
+ Status Code: 3.0
+
+ Status Description: Invalid property name.
+
+ Status Exception Data: Property name MAY be specified.
+
+ Description: iTIP operation failed because of an invalid property
+ name.
+
+3.6.14. Status Code 3.1
+
+ Status Code: 3.1
+
+ Status Description: Invalid property value.
+
+ Status Exception Data: Property name and value MAY be specified.
+
+ Description: iTIP operation failed because of an invalid property
+ value.
+
+3.6.15. Status Code 3.2
+
+ Status Code: 3.2
+
+ Status Description: Invalid property parameter.
+
+ Status Exception Data: Property parameter name and value MAY be
+ specified.
+
+ Description: iTIP operation failed because of an invalid property
+ parameter.
+
+
+
+
+
+Daboo Standards Track [Page 72]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.16. Status Code 3.3
+
+ Status Code: 3.3
+
+ Status Description: Invalid property parameter value.
+
+ Status Exception Data: Property parameter name and value MAY be
+ specified.
+
+ Description: iTIP operation failed because of an invalid property
+ parameter value.
+
+3.6.17. Status Code 3.4
+
+ Status Code: 3.4
+
+ Status Description: Invalid calendar component sequence.
+
+ Status Exception Data: Calendar component sentinel MAY be specified
+ (e.g., BEGIN:VTIMEZONE).
+
+ Description: iTIP operation failed because of an invalid component.
+
+3.6.18. Status Code 3.5
+
+ Status Code: 3.5
+
+ Status Description: Invalid date or time.
+
+ Status Exception Data: Date/time value(s) MAY be specified.
+
+ Description: iTIP operation failed because of an invalid date or
+ time property.
+
+3.6.19. Status Code 3.6
+
+ Status Code: 3.6
+
+ Status Description: Invalid rule.
+
+ Status Exception Data: RRULE property value MAY be specified.
+
+ Description: iTIP operation failed because of an invalid rule
+ property.
+
+
+
+
+
+
+
+Daboo Standards Track [Page 73]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.20. Status Code 3.7
+
+ Status Code: 3.7
+
+ Status Description: Invalid Calendar User.
+
+ Status Exception Data: ATTENDEE property value MAY be specified.
+
+ Description: iTIP operation failed because of an invalid ATTENDEE
+ property.
+
+3.6.21. Status Code 3.8
+
+ Status Code: 3.8
+
+ Status Description: No authority.
+
+ Status Exception Data: METHOD and ATTENDEE property values MAY be
+ specified.
+
+ Description: iTIP operation failed because an Attendee does not have
+ suitable privileges for the operation.
+
+3.6.22. Status Code 3.9
+
+ Status Code: 3.9
+
+ Status Description: Unsupported version.
+
+ Status Exception Data: VERSION property name and value MAY be
+ specified.
+
+ Description: iTIP operation failed because the calendar data version
+ is not supported.
+
+3.6.23. Status Code 3.10
+
+ Status Code: 3.10
+
+ Status Description: Request entity too large.
+
+ Status Exception Data: None.
+
+ Description: iTIP operation failed because the calendar data was too
+ large.
+
+
+
+
+
+
+Daboo Standards Track [Page 74]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.24. Status Code 3.11
+
+ Status Code: 3.11
+
+ Status Description: Required component or property missing.
+
+ Status Exception Data: Component or property name MAY be specified.
+
+ Description: iTIP operation failed because the calendar data did not
+ contain a required property or component.
+
+3.6.25. Status Code 3.12
+
+ Status Code: 3.12
+
+ Status Description: Unknown component or property found.
+
+ Status Exception Data: Component or property name MAY be specified.
+
+ Description: iTIP operation failed because the calendar data
+ contained an unknown property or component.
+
+3.6.26. Status Code 3.13
+
+ Status Code: 3.13
+
+ Status Description: Unsupported component or property found.
+
+ Status Exception Data: Component or property name MAY be specified.
+
+ Description: iTIP operation failed because the calendar data
+ contained an unsupported property or component.
+
+3.6.27. Status Code 3.14
+
+ Status Code: 3.14
+
+ Status Description: Unsupported capability.
+
+ Status Exception Data: METHOD or action MAY be specified.
+
+ Description: iTIP operation failed because the operation is not
+ supported.
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 75]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.28. Status Code 4.0
+
+ Status Code: 4.0
+
+ Status Description: Event conflict. Date/time is busy.
+
+ Status Exception Data: DTSTART and DTEND property names and values
+ MAY be specified.
+
+ Description: iTIP operation failed because the event overlaps the
+ date and time of another event.
+
+3.6.29. Status Code 5.0
+
+ Status Code: 5.0
+
+ Status Description: Request not supported.
+
+ Status Exception Data: METHOD property value MAY be specified.
+
+ Description: iTIP operation failed because the operation is not
+ supported.
+
+3.6.30. Status Code 5.1
+
+ Status Code: 5.1
+
+ Status Description: Service unavailable.
+
+ Status Exception Data: ATTENDEE property value MAY be specified.
+
+ Description: iTIP operation failed because scheduling is not active.
+
+3.6.31. Status Code 5.2
+
+ Status Code: 5.2
+
+ Status Description: Invalid calendar service.
+
+ Status Exception Data: ATTENDEE property value MAY be specified.
+
+ Description: iTIP operation failed because there is no scheduling
+ capability.
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 76]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.32. Status Code 5.3
+
+ Status Code: 5.3
+
+ Status Description: No scheduling support for user.
+
+ Status Exception Data: ATTENDEE property value MAY be specified.
+
+ Description: iTIP operation failed because scheduling is not enabled
+ for an Attendee.
+
+3.7. Implementation Considerations
+
+3.7.1. Working With Recurrence Instances
+
+ iCalendar includes a recurrence grammar to represent recurring
+ events. The benefit of such a grammar is the ability to represent a
+ number of events in a single object. However, while this simplifies
+ creation of a recurring event, meeting instances still need to be
+ referenced. For instance, an "Attendee" may decline the third
+ instance of a recurring Friday event. Similarly, the "Organizer" may
+ change the time or location to a single instance of the recurring
+ event.
+
+ Since implementations may elect to store recurring events as either a
+ single event object or a collection of discrete, related event
+ objects, the protocol is designed so that each recurring instance may
+ be both referenced and versioned. Hence, implementations that choose
+ to maintain per-instance properties (such as "ATTENDEE" property
+ "PARTSTAT" parameter) may do so. However, the protocol does not
+ require per-instance recognition unless the instance itself must be
+ renegotiated.
+
+ The scenarios for recurrence instance referencing are listed below.
+ For purposes of simplification, a change to an event refers to a
+ "trigger property." That is, a property that has a substantive
+ effect on the meeting itself, such as start time, location, due date
+ (for "VTODO" calendar components), and possibly description.
+
+ "Organizer"-initiated actions:
+
+ o deletes or changes a single instance of a recurring event
+
+ o makes changes that affect all future instances
+
+ o makes changes that affect all previous instances
+
+ o deletes or modifies a previously changed instance
+
+
+
+Daboo Standards Track [Page 77]
+
+RFC 5546 iTIP December 2009
+
+
+ "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,
+ "RECURRENCE-ID" property, when that instance is renegotiated.
+ 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,
+ due date, or location). The "Organizer" can identify a specific
+ recurrence instance using the "RECURRENCE-ID" property. The property
+ value is equal to the date/time of the instance. If the "Organizer"
+ wishes to change the "DTSTART", the original, unmodified "DTSTART"
+ value of the instance is used as the value "RECURRENCE-ID" property,
+ and the new "DTSTART" and "DTEND" values reflect the change.
+
+3.7.2. Attendee Property Considerations
+
+ The "ORGANIZER" property is required on published events, to-dos, and
+ journal entries for two reasons. First, only the "Organizer" is
+ allowed to update and redistribute an event or to-do component. It
+ follows that the "ORGANIZER" property MUST be present in the event,
+ to-do, or journal entry component so that the CUA has a basis for
+ authorizing an update. Second, it is prudent to provide a point of
+ contact for anyone who receives a published component, in case of
+ problems.
+
+ Email addresses that correspond to groups of "Calendar Users" could
+ be specified as a mailto: URI [RFC2368] calendar user address.
+ Sending email to such an address results in email being sent to
+ multiple recipients. Such an address may be used as the value of an
+ "ATTENDEE" property. Thus, it is possible that the recipient of a
+ "REQUEST" does not appear explicitly in the list.
+
+ It is recommended that the general approach to finding a "Calendar
+ User" in an "Attendee" list be as follows:
+
+ 1. Search for the "Calendar User" in the "Attendee" list where
+ "CUTYPE=INDIVIDUAL"
+
+ 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
+ sent to the "Organizer" MUST contain a new "ATTENDEE" property in
+ which:
+
+ * the "TYPE" property parameter is set to INDIVIDUAL
+
+
+
+Daboo Standards Track [Page 78]
+
+RFC 5546 iTIP December 2009
+
+
+ * the "MEMBER" property parameter is set to the name of the
+ group
+
+ 3. Failing (2), the CUA MAY ignore or accept the request as the
+ "Calendar User" wishes.
+
+3.7.3. Extension Tokens
+
+ To make iCalendar objects extensible, new component, property, or
+ property parameters can be used. Two types of extensions are defined
+ by [RFC5545]: IANA-registered tokens ("iana-token") and experimental
+ use tokens ("x-name"). A client SHOULD save "iana-token's" and MAY
+ use them in replies. A client MAY save "x-name's" and MAY use them
+ in replies. When delegating or forwarding messages to other CUs, a
+ client SHOULD include "iana-token's" and "x-names's".
+
+4. Examples
+
+4.1. Published Event Examples
+
+ In the calendaring and scheduling context, publication refers to the
+ one-way transfer of event information. Consumers of published events
+ simply incorporate the event into a calendar. No reply is expected.
+ Individual "A" publishes an event. Individual "B" reads the event
+ and incorporates it into their calendar. Events are published in
+ several ways, including embedding the event as an object in a web
+ page, emailing the event to a distribution list, or posting the event
+ to a newsgroup.
+
+ The table below illustrates the sequence of events between the
+ publisher and the consumers of a published event.
+
+ +----------------+-----------------------+--------------------------+
+ | Action | Organizer | Receiver |
+ +----------------+-----------------------+--------------------------+
+ | Publish an | "A" sends or posts a | "B" reads a published |
+ | event | PUBLISH message. | event. |
+ | | | |
+ | Publish an | "A" sends or posts a | "B" reads the updated |
+ | updated event | PUBLISH message. | event. |
+ | | | |
+ | Cancel a | "A" sends or posts a | "B" reads the canceled |
+ | published | CANCEL message. | event publication. |
+ | event | | |
+ +----------------+-----------------------+--------------------------+
+
+
+
+
+
+
+Daboo Standards Track [Page 79]
+
+RFC 5546 iTIP December 2009
+
+
+4.1.1. A Minimal Published Event
+
+ 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
+ properties for a "PUBLISH" for a "VEVENT" calendar component.
+
+ BEGIN:VCALENDAR
+ METHOD:PUBLISH
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ DTSTART:19970701T200000Z
+ DTSTAMP:19970611T190000Z
+ SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
+ UID:0981234-1234234-23@example.com
+ END:VEVENT
+ END:VCALENDAR
+
+4.1.2. Changing a Published Event
+
+ The iCalendar object below describes an update to the event described
+ in Section 4.1.1; the time has been changed, an end time has been
+ added, and the sequence number has been adjusted.
+
+ BEGIN:VCALENDAR
+ METHOD:PUBLISH
+ VERSION:2.0
+ PRODID:-//Example/ExampleCalendarClient//EN
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ DTSTAMP:19970612T190000Z
+ DTSTART:19970701T210000Z
+ DTEND:19970701T230000Z
+ SEQUENCE:1
+ UID:0981234-1234234-23@example.com
+ SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
+ END:VEVENT
+ END:VCALENDAR
+
+ The "UID" property is used by the client to identify the event. The
+ "SEQUENCE" property indicates that this is a change to the event.
+ The event with a matching "UID" and sequence number 0 is superseded
+ by this event.
+
+ The "SEQUENCE" property provides a reliable way to distinguish
+ different versions of the same event. Each time an event is
+ published, its sequence number is incremented. If a client receives
+
+
+
+Daboo Standards Track [Page 80]
+
+RFC 5546 iTIP December 2009
+
+
+ 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
+ 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
+ updated.
+
+4.1.3. Canceling a Published Event
+
+ The iCalendar object below cancels the event described in
+ Section 4.1.1. This cancels the event with "SEQUENCE" property of 0,
+ 1, and 2.
+
+ BEGIN:VCALENDAR
+ METHOD:CANCEL
+ VERSION:2.0
+ PRODID:-//Example/ExampleCalendarClient//EN
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ COMMENT:DUKES forfeit the game
+ SEQUENCE:2
+ UID:0981234-1234234-23@example.com
+ DTSTAMP:19970613T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.1.4. A Rich Published Event
+
+ This example describes the same event as in Section 4.1.1, but in
+ much greater detail.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:PUBLISH
+ SCALE:GREGORIAN
+ VERSION:2.0
+ BEGIN:VTIMEZONE
+ TZID:America-Chicago
+ TZURL:http://example.com/tz/America-Chicago
+ BEGIN:STANDARD
+ DTSTART:19671029T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0600
+ TZNAME:CST
+ END:STANDARD
+ BEGIN:DAYLIGHT
+ DTSTART:19870405T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+
+
+
+Daboo Standards Track [Page 81]
+
+RFC 5546 iTIP December 2009
+
+
+ TZOFFSETFROM:-0600
+ TZOFFSETTO:-0500
+ TZNAME:CDT
+ END:DAYLIGHT
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTACH:http://www.example.com/
+ CATEGORIES:SPORTS EVENT,ENTERTAINMENT
+ CLASS:PRIVATE
+ DESCRIPTION:MIDWAY STADIUM\n
+ Big time game. MUST see.\n
+ Expected duration:2 hours\n
+ DTEND;TZID=America-Chicago:19970701T180000
+ DTSTART;TZID=America-Chicago:19970702T160000
+ DTSTAMP:19970614T190000Z
+ STATUS:CONFIRMED
+ LOCATION;VALUE=URI:http://stadium.example.com/
+ PRIORITY:2
+ RESOURCES:SCOREBOARD
+ SEQUENCE:3
+ SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
+ UID:0981234-1234234-23@example.com
+ RELATED-TO:0981234-1234234-14@example.com
+ BEGIN:VALARM
+ TRIGGER:-PT2H
+ ACTION:DISPLAY
+ DESCRIPTION:You should be leaving for the game now.
+ END:VALARM
+ BEGIN:VALARM
+ TRIGGER:-PT30M
+ ACTION:AUDIO
+ END:VALARM
+ END:VEVENT
+ END:VCALENDAR
+
+ The "RELATED-TO" field contains the "UID" property of a related
+ calendar event. The "SEQUENCE" property 3 indicates that this event
+ supersedes versions 0, 1, and 2.
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 82]
+
+RFC 5546 iTIP December 2009
+
+
+4.1.5. Anniversaries or Events Attached to Entire Days
+
+ This example demonstrates the use of the "VALUE" parameter to tie a
+ "VEVENT" to a day rather than a specific time.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:PUBLISH
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ DTSTAMP:19970614T190000Z
+ UID:0981234-1234234-23@example.com
+ DTSTART;VALUE=DATE:19970714
+ RRULE:FREQ=YEARLY;INTERVAL=1
+ SUMMARY: Bastille Day
+ END:VEVENT
+ END:VCALENDAR
+
+4.2. Group Event Examples
+
+ Group events are distinguished from published events in that they
+ have "Attendees" and there is interaction between the "Attendees" and
+ the "Organizer" with respect to the event. Individual "A" requests a
+ meeting between individuals "A", "B", "C", and "D". Individual "B"
+ confirms attendance to the meeting. Individual "C" declines
+ attendance. Individual "D" tentatively confirms attendance. The
+ following table illustrates the message flow between these
+ individuals. "A", the CU scheduling the meeting, is referenced as
+ the "Organizer".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 83]
+
+RFC 5546 iTIP December 2009
+
+
+ +--------------+-----------------------+----------------------------+
+ | Action | "Organizer" | Attendee |
+ +--------------+-----------------------+----------------------------+
+ | Initiate a | "A" sends a REQUEST | |
+ | meeting | message to "B", "C", | |
+ | request | and "D". | |
+ | | | |
+ | Accept the | | "B" sends a REPLY message |
+ | meeting | | to "A" with its ATTENDEE |
+ | request | | PARTSTAT parameter set to |
+ | | | ACCEPTED. |
+ | | | |
+ | Decline the | | "C" sends a REPLY message |
+ | meeting | | to "A" with its ATTENDEE |
+ | request | | PARTSTAT parameter set to |
+ | | | DECLINED. |
+ | | | |
+ | Tentatively | | "D" sends a REPLY message |
+ | accept the | | to "A" with its ATTENDEE |
+ | meeting | | PARTSTAT parameter set to |
+ | request | | TENTATIVE. |
+ | | | |
+ | Confirm | "A" sends a REQUEST | |
+ | meeting | message to "B" and | |
+ | status with | "D" with updated | |
+ | Attendees | information. | |
+ +--------------+-----------------------+----------------------------+
+
+4.2.1. A Group Event Request
+
+ A sample meeting request is sent from "A" to "B", "C", and "D". "E"
+ is also sent a copy of the request but is not expected to attend and
+ need not reply. "E" illustrates how CUAs might implement an "FYI"-
+ type feature. Note the use of the "ROLE" parameter. The default
+ value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not
+ be enumerated. In this case, we are using the value "NON-
+ PARTICIPANT" to indicate "E" is a non-attending CU. The parameter is
+ not needed on other "Attendees" since "PARTICIPANT" is the default
+ value.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER: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
+
+
+
+Daboo Standards Track [Page 84]
+
+RFC 5546 iTIP December 2009
+
+
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com
+ ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big@example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com
+ DTSTAMP:19970611T190000Z
+ DTSTART:19970701T200000Z
+ DTEND:19970701T2100000Z
+ SUMMARY:Conference
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.2. Reply to a Group Event Request
+
+ "Attendee" "B" accepts the meeting.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VEVENT
+ ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com
+ ORGANIZER:mailto:a@example.com
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ REQUEST-STATUS:2.0;Success
+ DTSTAMP:19970612T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+ "B" could have declined the meeting or indicated tentative acceptance
+ by setting the "ATTENDEE" "PARTSTAT" parameter to "DECLINED" or
+ "TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in
+ successful transactions.
+
+4.2.3. Update an Event
+
+ The event is moved to a different time. The combination of the "UID"
+ property (unchanged) and the "SEQUENCE" (bumped to 1) properties
+ indicate the update.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+
+
+
+Daboo Standards Track [Page 85]
+
+RFC 5546 iTIP December 2009
+
+
+ ORGANIZER: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:c@example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
+ CUTYPE=ROOM:mailto:conf@example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com
+ DTSTART:19970701T180000Z
+ DTEND:19970701T190000Z
+ SUMMARY:Phone Conference
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:1
+ DTSTAMP:19970613T190000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.4. Countering an Event Proposal
+
+ "A" sends a "REQUEST" to "B" and "C". "B" makes a counter proposal
+ to "A" to change the time and location.
+
+ "A" sends the following "REQUEST":
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER: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:c@example.com
+ DTSTART:19970701T190000Z
+ DTEND:19970701T200000Z
+ SUMMARY:Discuss the Merits of the election results
+ LOCATION:Green Conference Room
+ UID:calsrv.example.com-873970198738777a@example.com
+ SEQUENCE:0
+ DTSTAMP:19970611T190000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+
+
+
+
+
+
+Daboo Standards Track [Page 86]
+
+RFC 5546 iTIP December 2009
+
+
+ "B" sends "COUNTER" to "A", requesting changes to time and place.
+ "B" uses the "COMMENT" property to communicate a rationale for the
+ change. Note that the "SEQUENCE" property is not incremented on a
+ "COUNTER".
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:COUNTER
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER: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:c@example.com
+ DTSTART:19970701T160000Z
+ DTEND:19970701T170000Z
+ DTSTAMP:19970612T190000Z
+ SUMMARY:Discuss the Merits of the election results
+ LOCATION:Blue Conference Room
+ COMMENT:This time works much better and I think the big conference
+ room is too big
+ UID:calsrv.example.com-873970198738777a@example.com
+ SEQUENCE:0
+ END:VEVENT
+ END:VCALENDAR
+
+ "A" accepts the changes from "B". To accept a counter proposal, the
+ "Organizer" sends a new event "REQUEST" with an incremented sequence
+ number.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER: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:c@example.com
+ DTSTAMP:19970613T190000Z
+ DTSTART:19970701T160000Z
+ DTEND:19970701T170000Z
+ SUMMARY:Discuss the Merits of the election results - changed to
+ meet B's schedule
+ LOCATION:Blue Conference Room
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:1
+ STATUS:CONFIRMED
+
+
+
+Daboo Standards Track [Page 87]
+
+RFC 5546 iTIP December 2009
+
+
+ END:VEVENT
+ END:VCALENDAR
+
+ Instead, "A" rejects "B's" counter proposal.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:DECLINECOUNTER
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
+ COMMENT:Sorry, I cannot change this meeting time
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ DTSTAMP:19970614T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.5. Delegating an Event
+
+ When delegating an event request to another "Calendar User", the
+ "Delegator" must both update the "Organizer" with a "REPLY" and send
+ a request to the "Delegate". There is currently no protocol
+ limitation to delegation depth. It is possible for the original
+ delegate to delegate the meeting to someone else, and so on. When a
+ request is delegated from one CUA to another, there are a number of
+ responsibilities required of the "Delegator". The "Delegator" MUST:
+
+ o Send a "REPLY" to the "Organizer" with the following updates:
+
+ A. The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter is
+ 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
+ the "DELEGATED-FROM" property parameter set to the
+ "Delegator".
+
+ C. Indicate whether they want to continue to receive updates when
+ the "Organizer" sends out updated versions of the event.
+ Setting the "RSVP" property parameter to "TRUE" will cause the
+ updates to be sent; setting it to "FALSE" causes no further
+ updates to be sent. Note that in either case, if the
+ "Delegate" declines the invitation, the "Delegator" will be
+ notified.
+
+
+
+
+
+Daboo Standards Track [Page 88]
+
+RFC 5546 iTIP December 2009
+
+
+ o The "Delegator" MUST also send a copy of the original "REQUEST"
+ method to the "Delegate", with changes (A) and (B), as detailed
+ above applied.
+
+ If the "Delegate" declines the meeting, the "Organizer" MUST send an
+ update "REQUEST" to the "Delegator" so that the "Delegator" may elect
+ to delegate the "REQUEST" to another CUA.
+
+ +----------------+-----------------+--------------------------------+
+ | Action | "Organizer" | Attendee |
+ +----------------+-----------------+--------------------------------+
+ | Initiate a | "A" sends a | |
+ | meeting | REQUEST message | |
+ | request | to "B" and "C". | |
+ | | | |
+ | Delegate: "C" | | "C" sends a REPLY to "A" with |
+ | delegates to | | the ATTENDEE PARTSTAT |
+ | "E" | | parameter set to DELEGATED and |
+ | | | with a new ATTENDEE property |
+ | | | for "E". "E's" ATTENDEE |
+ | | | DELEGATED-FROM parameter is |
+ | | | set to "C". "C's" ATTENDEE |
+ | | | DELEGATED-TO parameter is set |
+ | | | to "E". "C" sends REQUEST |
+ | | | message to "E" with the |
+ | | | original meeting request |
+ | | | information. The PARTSTAT |
+ | | | property parameter for "C" is |
+ | | | set to DELEGATED and the |
+ | | | DELEGATED-TO parameter is set |
+ | | | to the address of "E". An |
+ | | | ATTENDEE property is added for |
+ | | | "E" and the DELEGATED-FROM |
+ | | | parameter is set to the |
+ | | | address of "C". |
+ | | | |
+ | Confirm | | "E" sends REPLY message to |
+ | meeting | | "A", and optionally to "C", |
+ | attendance | | with its PARTSTAT property |
+ | | | parameter set to ACCEPTED. |
+ | | | |
+ | Optional: | "A" sends | |
+ | Redistribute | REQUEST message | |
+ | meeting to | to "B", "C", | |
+ | Attendees | and "E". | |
+ +----------------+-----------------+--------------------------------+
+
+
+
+
+
+Daboo Standards Track [Page 89]
+
+RFC 5546 iTIP December 2009
+
+
+ "C" responds to the "Organizer".
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
+ TO="mailto:e@example.com":mailto:c@example.com
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ REQUEST-STATUS:2.0;Success
+ DTSTAMP:19970611T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+ "Attendee" "C" delegates presence at the meeting to "E".
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
+ TO="mailto:e@example.com":mailto:c@example.com
+ ATTENDEE;RSVP=TRUE;
+ DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
+ DTSTART:19970701T180000Z
+ DTEND:19970701T200000Z
+ SUMMARY:Phone Conference
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ STATUS:CONFIRMED
+ DTSTAMP:19970611T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.6. Delegate Accepts the Meeting
+
+ To accept a delegated meeting, the delegate, "E", sends the following
+ message to "A" and "C".
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REPLY
+ VERSION:2.0
+
+
+
+Daboo Standards Track [Page 90]
+
+RFC 5546 iTIP December 2009
+
+
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
+ FROM="mailto:c@example.com":mailto:e@example.com
+ ATTENDEE;PARTSTAT=DELEGATED;
+ DELEGATED-TO="mailto:e@example.com":mailto:c@example.com
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ REQUEST-STATUS:2.0;Success
+ DTSTAMP:19970614T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.7. Delegate Declines the Meeting
+
+ In this example, the "Delegate" declines the meeting request and sets
+ the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The
+ "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT"
+ parameter of the "Delegate" set to "DECLINED". This lets the
+ "Delegator" know that the "Delegate" has declined and provides an
+ opportunity to the "Delegator" to either accept the request or
+ delegate it to another CU.
+
+ "E" responds to "A" and "C". Note the use of the "COMMENT" property
+ "E" uses to indicate why the delegation was declined.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;PARTSTAT=DELEGATED;
+ DELEGATED-TO="mailto:e@example.com":mailto:c@example.com
+ ATTENDEE;PARTSTAT=DECLINED;
+ DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
+ COMMENT:Sorry, I will be out of town at that time.
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ REQUEST-STATUS:2.0;Success
+ DTSTAMP:19970614T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+ "A" resends the "REQUEST" method to "C". "A" may also wish to
+ express the fact that the item was delegated in the "COMMENT"
+ property.
+
+
+
+
+Daboo Standards Track [Page 91]
+
+RFC 5546 iTIP December 2009
+
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;PARTSTAT=DECLINED;
+ DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
+ ATTENDEE;RSVP=TRUE:mailto:c@example.com
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ SUMMARY:Phone Conference
+ DTSTART:19970701T180000Z
+ DTEND:19970701T200000Z
+ DTSTAMP:19970614T200000Z
+ COMMENT:DELEGATE (ATTENDEE mailto:e@example.com) DECLINED YOUR
+ INVITATION
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.8. Forwarding an Event Request
+
+ The protocol does not prevent an "Attendee" from "forwarding" a
+ "VEVENT" calendar component to other "Calendar Users". Forwarding
+ differs from delegation in that the forwarded "Calendar User" (often
+ referred to as a "Party Crasher") does not replace the forwarding
+ "Calendar User". Implementations are not required to add the "Party
+ Crasher" to the "Attendee" list, and hence there is no guarantee that
+ a "Party Crasher" will receive additional updates to the event. The
+ forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the
+ "Attendee" list. The "Organizer" MAY add the forwarded "Calendar
+ User" to the "Attendee" list.
+
+4.2.9. Cancel a Group Event
+
+ Individual "A" requests a meeting between individuals "A", "B", "C",
+ and "D". Individual "B" declines attendance to the meeting.
+ Individual "A" decides to cancel the meeting. The following table
+ illustrates the sequence of messages that would be exchanged between
+ these individuals.
+
+ Messages related to a previously canceled event ("SEQUENCE" property
+ value is less than the "SEQUENCE" property value of the "CANCEL"
+ message) MUST be ignored.
+
+
+
+
+
+
+
+Daboo Standards Track [Page 92]
+
+RFC 5546 iTIP December 2009
+
+
+ +-------------+---------------------+-------------------------------+
+ | Action | Organizer | Attendee |
+ +-------------+---------------------+-------------------------------+
+ | Initiate a | "A" sends a REQUEST | |
+ | meeting | message to "B", | |
+ | request | "C", and "D". | |
+ | | | |
+ | Decline the | | "B" sends a REPLY message to |
+ | meeting | | "A" with its PARTSTAT |
+ | request | | parameter set to DECLINED. |
+ | | | |
+ | Cancel the | "A" sends a CANCEL | |
+ | meeting | message to "B", | |
+ | | "C", and "D". | |
+ +-------------+---------------------+-------------------------------+
+
+ This example shows how "A" cancels the event.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:CANCEL
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL;mailto:a@example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:b@example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
+ COMMENT:Mr. B cannot attend. It's raining. Lets cancel.
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:1
+ STATUS:CANCELLED
+ DTSTAMP:19970613T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.10. Removing Attendees
+
+ "A" wants to remove "B" from a meeting. This is done by sending a
+ "CANCEL" to "B" and removing "B" from the "Attendee" list in the
+ master copy of the event.
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 93]
+
+RFC 5546 iTIP December 2009
+
+
+ +--------------------+-----------------------------------+----------+
+ | Action | Organizer | Attendee |
+ +--------------------+-----------------------------------+----------+
+ | Remove "B" as an | "A" sends a CANCEL message to | |
+ | Attendee | "B". | |
+ | | | |
+ | Update the master | "A" optionally sends the updated | |
+ | copy of the event | event to the remaining Attendees. | |
+ +--------------------+-----------------------------------+----------+
+
+ The original meeting includes "A", "B", "C", and "D". The example
+ below shows the "CANCEL" that "A" sends to "B". Note that in the
+ example below, the "STATUS" property is omitted. This is used when
+ the meeting itself is cancelled and not when the intent is to remove
+ an "Attendee" from the event.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:CANCEL
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ COMMENT:You're off the hook for this meeting
+ UID:calsrv.example.com-873970198738777@example.com
+ DTSTAMP:19970613T193000Z
+ SEQUENCE:1
+ END:VEVENT
+ END:VCALENDAR
+
+ The updated master copy of the event is shown below. The "Organizer"
+ MAY resend the updated event to the remaining "Attendees". Note that
+ "B" has been removed.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
+ ATTENDEE;CUTYPE=ROOM:mailto:cr_big@example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;
+ RSVP=FALSE:mailto:e@example.com
+ DTSTAMP:19970611T190000Z
+ DTSTART:19970701T200000Z
+
+
+
+Daboo Standards Track [Page 94]
+
+RFC 5546 iTIP December 2009
+
+
+ DTEND:19970701T203000Z
+ SUMMARY:Phone Conference
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:2
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.11. Replacing the Organizer
+
+ The scenario for this example begins with "A" as the "Organizer" for
+ a recurring meeting with "B", "C", and "D". "A" receives a new job
+ offer in another country and drops out of touch. "A" left no
+ forwarding address or way to be reached. Using out-of-band
+ communication, the other "Attendees" eventually learn what has
+ happened and reach an agreement that "B" should become the new
+ "Organizer" for the meeting. To do this, "B" sends out a new version
+ of the event and the other "Attendees" agree to accept "B" as the new
+ "Organizer". "B" also removes "A" from the event.
+
+ When the "Organizer" is replaced, the "SEQUENCE" property value MUST
+ be incremented.
+
+ This is the message "B" sends to "C" and "D".
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:b@example.com
+ ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:mailto:b@example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
+ DTSTAMP:19970611T190000Z
+ DTSTART:19970701T200000Z
+ DTEND:19970701T203000Z
+ RRULE:FREQ=WEEKLY
+ SUMMARY:Phone Conference
+ UID:123456@example.com
+ SEQUENCE:1
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+
+
+
+
+
+
+Daboo Standards Track [Page 95]
+
+RFC 5546 iTIP December 2009
+
+
+4.3. Busy Time Examples
+
+ Busy time objects can be used in several ways. First, a CU may
+ request busy time from another CU for a specific range of time. That
+ request can be answered with a busy time "REPLY". Additionally, a CU
+ may simply publish their busy time for a given interval and point
+ other CUs to the published location. The following examples outline
+ both scenarios.
+
+4.3.1. Publish Busy Time
+
+ Individual "A" publishes busy time for one week.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ METHOD:PUBLISH
+ BEGIN:VFREEBUSY
+ DTSTAMP:19980101T124100Z
+ ORGANIZER:mailto:a@example.com
+ DTSTART:19980101T124200Z
+ DTEND:19980108T124200Z
+ FREEBUSY:19980101T180000Z/19980101T190000Z
+ FREEBUSY:19980103T020000Z/19980103T050000Z
+ FREEBUSY:19980107T020000Z/19980107T050000Z
+ FREEBUSY:19980113T000000Z/19980113T010000Z
+ FREEBUSY:19980115T190000Z/19980115T200000Z
+ FREEBUSY:19980115T220000Z/19980115T230000Z
+ FREEBUSY:19980116T013000Z/19980116T043000Z
+ END:VFREEBUSY
+ END:VCALENDAR
+
+4.3.2. Request Busy Time
+
+ Individual "A" requests busy time from individuals "B" and "C".
+ Individuals "B" and "C" reply with busy time data to individual "A".
+ The following table illustrates the sequence of messages that would
+ be exchanged between these individuals.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 96]
+
+RFC 5546 iTIP December 2009
+
+
+ +---------------------+--------------------+------------------------+
+ | Action | Organizer | Attendee |
+ +---------------------+--------------------+------------------------+
+ | Initiate a busy | "A" sends REQUEST | |
+ | time request | message to "B" and | |
+ | | "C". | |
+ | | | |
+ | Reply to the BUSY | | "B" sends a REPLY |
+ | request with BUSY | | message to "A" with |
+ | time data | | busy time data. |
+ +---------------------+--------------------+------------------------+
+
+ "A" sends a "REQUEST" to "B" and "C" for busy time.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VFREEBUSY
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ ATTENDEE:mailto:c@example.com
+ DTSTAMP:19970613T190000Z
+ DTSTART:19970701T080000Z
+ DTEND:19970701T200000
+ UID:calsrv.example.com-873970198738777@example.com
+ END:VFREEBUSY
+ END:VCALENDAR
+
+4.3.3. Reply to a Busy Time Request
+
+ "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component
+ to "A".
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VFREEBUSY
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ DTSTART:19970701T080000Z
+ DTEND:19970701T200000Z
+ UID:calsrv.example.com-873970198738777@example.com
+ FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M
+ DTSTAMP:19970613T190030Z
+ END:VFREEBUSY
+
+
+
+Daboo Standards Track [Page 97]
+
+RFC 5546 iTIP December 2009
+
+
+ END:VCALENDAR
+
+ "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30.
+
+4.4. Recurring Event and Time Zone Examples
+
+4.4.1. A Recurring Event Spanning Time Zones
+
+ This event describes a weekly phone conference. The "Attendees" are
+ each in a different time zone.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VTIMEZONE
+ TZID:America-SanJose
+ TZURL:http://example.com/tz/America-SanJose
+ BEGIN:STANDARD
+ DTSTART:19671029T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZOFFSETFROM:-0700
+ TZOFFSETTO:-0800
+ TZNAME:PST
+ END:STANDARD
+ BEGIN:DAYLIGHT
+ DTSTART:19870405T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZOFFSETFROM:-0800
+ TZOFFSETTO:-0700
+ TZNAME:PDT
+ END:DAYLIGHT
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;
+ CUTYPE=INDIVIDUAL:a@example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:b@example.fr
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:c@example.jp
+ DTSTAMP:19970613T190030Z
+ DTSTART;TZID=America-SanJose:19970701T140000
+ DTEND;TZID=America-SanJose:19970701T150000
+ RRULE:FREQ=WEEKLY;COUNT=20;WKST=SU;BYDAY=TU
+ RDATE;TZID=America-SanJose:19970910T140000
+ EXDATE;TZID=America-SanJose:19970909T140000
+ EXDATE;TZID=America-SanJose:19971028T140000
+ SUMMARY:Weekly Phone Conference
+ UID:calsrv.example.com-873970198738777@example.com
+
+
+
+Daboo Standards Track [Page 98]
+
+RFC 5546 iTIP December 2009
+
+
+ SEQUENCE:0
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ The first component of this iCalendar object is the time zone
+ component. The "DTSTART" date coincides with the first instance of
+ the "RRULE" property.
+
+ The recurring meeting is defined in a particular time zone,
+ presumably that of the originator. The client for each "Attendee"
+ has the responsibility of determining the recurrence time in the
+ "Attendee's" time zone.
+
+ The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT
+ (UTC-7). "Attendee" B@example.fr is in France, where the local time
+ on this date is 9 hours ahead of PDT, or 23:00 CEST (UTC+2).
+ "Attendee" C@example.jp is in Japan, where local time is 16 hours
+ ahead of PDT, or Wednesday, July 2 at 06:00 JST (UTC+9). The event
+ repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property
+ results in 20 instances. The last instance falls on Tuesday,
+ November 11, 1997 2:00pm PST. The "RDATE" property adds another
+ instance: WED, 10-SEP-1997 2:00 PM PDT.
+
+ There are also two exception dates to the recurrence rule. The first
+ one is:
+
+ o TUE, 09-SEP-1997 14:00 PDT (UTC-7)
+
+ o TUE, 09-SEP-1997 23:00 CEST (UTC+2)
+
+ o WED, 10-SEP-1997 06:00 JST (UTC+9)
+
+
+ and the second is:
+
+ o TUE, 28-OCT-1997 14:00 PST (UTC-8)
+
+ o TUE, 28-OCT-1997 23:00 CET (UTC+1)
+
+ o WED, 29-OCT-1997 07:00 JST (UTC+9)
+
+4.4.2. Modify a Recurring Instance
+
+ In this example, the "Organizer" issues a recurring meeting. Later,
+ the "Organizer" changes an instance of the event by changing the
+ "DTSTART" property. Note the use of "RECURRENCE-ID" property and
+ "SEQUENCE" property in the second request.
+
+
+
+Daboo Standards Track [Page 99]
+
+RFC 5546 iTIP December 2009
+
+
+ Original Request:
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:guid-1@example.com
+ SEQUENCE:0
+ RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ ATTENDEE:mailto:c@example.com
+ ATTENDEE:mailto:d@example.com
+ DESCRIPTION:IETF-C&S Conference Call
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970601T210000Z
+ DTEND:19970601T220000Z
+ LOCATION:Conference Call
+ DTSTAMP:19970526T083000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ The event request below is to change the time of a specific instance.
+ This changes the July 1st instance to July 3rd.
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:guid-1@example.com
+ RECURRENCE-ID:19970701T210000Z
+ SEQUENCE:1
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ ATTENDEE:mailto:c@example.com
+ ATTENDEE:mailto:d@example.com
+ DESCRIPTION:IETF-C&S Conference Call
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970703T210000Z
+ DTEND:19970703T220000Z
+ LOCATION:Conference Call
+
+
+
+Daboo Standards Track [Page 100]
+
+RFC 5546 iTIP December 2009
+
+
+ DTSTAMP:19970626T093000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.4.3. Cancel an Instance
+
+ In this example, the "Organizer" of a recurring event deletes the
+ August 1st instance.
+
+ BEGIN:VCALENDAR
+ METHOD:CANCEL
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:guid-1@example.com
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ ATTENDEE:mailto:c@example.com
+ ATTENDEE:mailto:d@example.com
+ RECURRENCE-ID:19970801T210000Z
+ SEQUENCE:2
+ STATUS:CANCELLED
+ DTSTAMP:19970721T093000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.4.4. Cancel a Recurring Event
+
+ In this example, the "Organizer" wishes to cancel the entire
+ recurring event and any exceptions.
+
+ BEGIN:VCALENDAR
+ METHOD:CANCEL
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:guid-1@example.com
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ ATTENDEE:mailto:c@example.com
+ ATTENDEE:mailto:d@example.com
+ DTSTAMP:19970721T103000Z
+ STATUS:CANCELLED
+ SEQUENCE:3
+ END:VEVENT
+
+
+
+Daboo Standards Track [Page 101]
+
+RFC 5546 iTIP December 2009
+
+
+ END:VCALENDAR
+
+4.4.5. Change All Future Instances
+
+ This example changes the meeting location from a conference call to
+ Seattle, starting September 1 and extending to all future instances.
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:guid-1@example.com
+ RECURRENCE-ID;THISANDFUTURE:19970901T210000Z
+ SEQUENCE:3
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ ATTENDEE;RSVP=TRUE:mailto:c@example.com
+ ATTENDEE;RSVP=TRUE:mailto:d@example.com
+ DESCRIPTION:IETF-C&S Discussion
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970901T210000Z
+ DTEND:19970901T220000Z
+ LOCATION:Building 32, Microsoft, Seattle, WA
+ DTSTAMP:19970526T083000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.4.6. Add a New Instance to a Recurring Event
+
+ This example adds a one-time additional instance to the recurring
+ event. "Organizer" adds a second July meeting on the 15th.
+
+ BEGIN:VCALENDAR
+ METHOD:ADD
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:123456789@example.com
+ SEQUENCE:4
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ ATTENDEE;RSVP=TRUE:mailto:c@example.com
+ ATTENDEE;RSVP=TRUE:mailto:d@example.com
+
+
+
+Daboo Standards Track [Page 102]
+
+RFC 5546 iTIP December 2009
+
+
+ DESCRIPTION:IETF-C&S Conference Call
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970715T210000Z
+ DTEND:19970715T220000Z
+ LOCATION:Conference Call
+ DTSTAMP:19970629T093000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.4.7. Add a New Series of Instances to a Recurring Event
+
+ The scenario for this example involves an ongoing meeting, originally
+ set up to occur every Tuesday. The "Organizer" later decides that
+ the meetings need to be on Tuesdays and Thursdays.
+
+ The original event:
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:123456789@example.com
+ SEQUENCE:0
+ RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980303T210000Z
+ DTEND:19980303T220000Z
+ LOCATION:The White Room
+ DTSTAMP:19980301T093000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ The entire event can be rescheduled using a "REQUEST". This is done
+ by using the "UID" of the event to reschedule and including the
+ modified "RRULE". Note that since this is an entire rescheduling of
+ the event, any instance-specific information will be lost, unless
+ explicitly included with the update "REQUEST".
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//Example/ExampleCalendarClient//EN
+
+
+
+Daboo Standards Track [Page 103]
+
+RFC 5546 iTIP December 2009
+
+
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:123456789@example.com
+ SEQUENCE:7
+ RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980303T210000Z
+ DTEND:19980303T220000Z
+ DTSTAMP:19980303T193000Z
+ LOCATION:The White Room
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.4.8. Refreshing a Recurring Event
+
+ The next series of examples illustrate how an "Organizer" would
+ respond to a "REFRESH" submitted by an "Attendee" after a series of
+ instance-specific modifications. To convey all instance-specific
+ changes, the "Organizer" must provide the latest event description
+ and the relevant instances. The first three examples show the
+ history, including the initial "VEVENT" request and subsequent
+ instance changes, and finally the "REFRESH".
+
+ Original Request:
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:123456789@example.com
+ SEQUENCE:0
+ RDATE:19980304T180000Z
+ RDATE:19980311T180000Z
+ RDATE:19980318T180000Z
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980304T180000Z
+ DTEND:19980304T200000Z
+ DTSTAMP:19980303T193000Z
+ LOCATION:Conference Room A
+ STATUS:CONFIRMED
+
+
+
+Daboo Standards Track [Page 104]
+
+RFC 5546 iTIP December 2009
+
+
+ END:VEVENT
+ END:VCALENDAR
+
+ Organizer changes 2nd instance location and time:
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:123456789@example.com
+ SEQUENCE:1
+ RECURRENCE-ID:19980311T180000Z
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980311T160000Z
+ DTEND:19980311T180000Z
+ DTSTAMP:19980306T193000Z
+ LOCATION:The Small conference room
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ Organizer adds a 4th instance of the meeting using the "ADD" method.
+
+ BEGIN:VCALENDAR
+ METHOD:ADD
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:123456789@example.com
+ SEQUENCE:2
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980315T180000Z
+ DTEND:19980315T200000Z
+ DTSTAMP:19980307T193000Z
+ LOCATION:Conference Room A
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+
+
+
+
+
+Daboo Standards Track [Page 105]
+
+RFC 5546 iTIP December 2009
+
+
+ If "B" requests a "REFRESH", "A" responds with the following to
+ capture all instance-specific data. In this case, both the initial
+ request and an additional "VEVENT" that specifies the instance-
+ specific data are included. Because these are both of the same type
+ (they are both "VEVENTS"), they can be conveyed in the same iCalendar
+ object.
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:123456789@example.com
+ SEQUENCE:2
+ RDATE:19980304T180000Z
+ RDATE:19980311T160000Z
+ RDATE:19980315T180000Z
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980304T180000Z
+ DTEND:19980304T200000Z
+ DTSTAMP:19980303T193000Z
+ LOCATION:Conference Room A
+ STATUS:CONFIRMED
+ END:VEVENT
+ BEGIN:VEVENT
+ SEQUENCE:2
+ UID:123456789@example.com
+ RECURRENCE-ID:19980311T160000Z
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980311T160000Z
+ DTEND:19980304T180000Z
+ DTSTAMP:19980306T193000Z
+ LOCATION:The Small conference room
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.4.9. Counter an Instance of a Recurring Event
+
+ In this example, one of the "Attendees" counters the "DTSTART"
+ property of the proposed second July meeting.
+
+
+
+
+
+Daboo Standards Track [Page 106]
+
+RFC 5546 iTIP December 2009
+
+
+ BEGIN:VCALENDAR
+ METHOD:COUNTER
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:guid-1@example.com
+ RECURRENCE-ID:19970715T210000Z
+ SEQUENCE:4
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;RSVP=TRUE:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ ATTENDEE;RSVP=TRUE:mailto:c@example.com
+ ATTENDEE;RSVP=TRUE:mailto:d@example.com
+ DESCRIPTION:IETF-C&S Conference Call
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970715T220000Z
+ DTEND:19970715T230000Z
+ LOCATION:Conference Call
+ COMMENT:May we bump this by an hour? I have a conflict
+ DTSTAMP:19970629T094000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.4.10. Error Reply to a Request
+
+ The following example illustrates a scenario where a meeting is
+ proposed containing an unsupported property and a bad property.
+
+ Original Request:
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:guid-1@example.com
+ SEQUENCE:0
+ RRULE:FREQ=MONTHLY;BYMONTHDAY=1
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ ATTENDEE;RSVP=TRUE:mailto:c@example.com
+ ATTENDEE;RSVP=TRUE:mailto:d@example.com
+ DESCRIPTION:IETF-C&S Conference Call
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970601T210000Z
+
+
+
+Daboo Standards Track [Page 107]
+
+RFC 5546 iTIP December 2009
+
+
+ DTEND:19970601T220000Z
+ DTSTAMP:19970602T094000Z
+ LOCATION:Conference Call
+ STATUS:CONFIRMED
+ FOO:BAR
+ END:VEVENT
+ END:VCALENDAR
+
+ "B" responds to indicate that "RRULE" is not supported and that an
+ unrecognized property was encountered.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ REQUEST-STATUS:3.0;Invalid Property Name;FOO
+ UID:guid-1@example.com
+ SEQUENCE:0
+ DTSTAMP:19970603T094000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.5. Group To-Do Examples
+
+ Individual "A" creates a group task in which individuals "A", "B",
+ "C", and "D" will participate. Individual "B" confirms acceptance of
+ the task. Individual "C" declines the task. Individual "D"
+ tentatively accepts the task. The following table illustrates the
+ sequence of messages that would be exchanged between these
+ individuals. Individual "A" then issues a "REQUEST" method to obtain
+ the status of the to-do from each participant. The response
+ indicates the individual "Attendee's" completion status. The table
+ below illustrates the message flow.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 108]
+
+RFC 5546 iTIP December 2009
+
+
+ +--------------+------------------------+---------------------------+
+ | Action | Organizer | Attendee |
+ +--------------+------------------------+---------------------------+
+ | Initiate a | "A" sends a REQUEST | |
+ | to-do | message to "B", "C", | |
+ | request | and "D". | |
+ | | | |
+ | Accept the | | "B" sends a REPLY message |
+ | to-do | | to "A" with its PARTSTAT |
+ | request | | parameter set to |
+ | | | ACCEPTED. |
+ | | | |
+ | Decline the | | "C" sends a REPLY message |
+ | to-do | | to "A" with its PARTSTAT |
+ | request | | parameter set to |
+ | | | DECLINED. |
+ | | | |
+ | Tentatively | | "D" sends a REPLY message |
+ | accept the | | to "A" with its PARTSTAT |
+ | to-do | | parameter set to |
+ | request | | TENTATIVE. |
+ | | | |
+ | Check | "A" sends a REQUEST | |
+ | Attendee | message to "B" and "D" | |
+ | completion | with current | |
+ | status | information. | |
+ | | | |
+ | Attendee | | "B" sends a REPLY message |
+ | indicates | | indicating percent |
+ | percent | | complete. |
+ | complete | | |
+ | | | |
+ | Attendee | | "D" sends a REPLY message |
+ | indicates | | indicating completion. |
+ | completion | | |
+ +--------------+------------------------+---------------------------+
+
+4.5.1. A VTODO Request
+
+ A sample "REQUEST" for a "VTODO" calendar component that "A" sends to
+ "B", "C", and "D".
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VTODO
+ ORGANIZER:mailto:a@example.com
+
+
+
+Daboo Standards Track [Page 109]
+
+RFC 5546 iTIP December 2009
+
+
+ ATTENDEE;ROLE=CHAIR:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE:mailto:b@example.com
+ ATTENDEE;RSVP=TRUE:mailto:c@example.com
+ ATTENDEE;RSVP=TRUE:mailto:d@example.com
+ DTSTART:19970701T170000Z
+ DUE:19970722T170000Z
+ PRIORITY:1
+ SUMMARY:Create the requirements document
+ UID:calsrv.example.com-873970198738777-00@example.com
+ SEQUENCE:0
+ DTSTAMP:19970717T200000Z
+ STATUS:NEEDS-ACTION
+ END:VTODO
+ END:VCALENDAR
+
+4.5.2. A VTODO Reply
+
+ "B" accepts the to-do.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VTODO
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com
+ UID:calsrv.example.com-873970198738777-00@example.com
+ COMMENT:I'll send you my input by email
+ SEQUENCE:0
+ DTSTAMP:19970717T203000Z
+ REQUEST-STATUS:2.0;Success
+ END:VTODO
+ END:VCALENDAR
+
+ "B" could have declined the "VTODO" or indicated tentative acceptance
+ by setting the "PARTSTAT" property parameter sequence to "DECLINED"
+ or "TENTATIVE", respectively.
+
+4.5.3. A VTODO Request for Updated Status
+
+ "A" requests status from all "Attendees".
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VTODO
+ ORGANIZER:mailto:a@example.com
+
+
+
+Daboo Standards Track [Page 110]
+
+RFC 5546 iTIP December 2009
+
+
+ ATTENDEE;ROLE=CHAIR:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com
+ UID:calsrv.example.com-873970198738777-00@example.com
+ SUMMARY:Create the requirements document
+ PRIORITY:1
+ SEQUENCE:0
+ STATUS:IN-PROCESS
+ DTSTART:19970701T170000Z
+ DTSTAMP:19970717T230000Z
+ END:VTODO
+ END:VCALENDAR
+
+4.5.4. A Reply: Percent-Complete
+
+ A reply indicating the task being worked on and that "B" is 75%
+ complete with "B's" part of the assignment.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VTODO
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com
+ PERCENT-COMPLETE:75
+ UID:calsrv.example.com-873970198738777-00@example.com
+ DTSTAMP:19970717T233000Z
+ SEQUENCE:0
+ END:VTODO
+ END:VCALENDAR
+
+4.5.5. A Reply: Completed
+
+ A reply indicating that "D" completed "D's" part of the assignment.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VTODO
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;PARTSTAT=COMPLETED:mailto:d@example.com
+ UID:calsrv.example.com-873970198738777-00@example.com
+ DTSTAMP:19970717T233000Z
+ SEQUENCE:0
+ END:VTODO
+ END:VCALENDAR
+
+
+
+Daboo Standards Track [Page 111]
+
+RFC 5546 iTIP December 2009
+
+
+4.5.6. An Updated VTODO Request
+
+ "Organizer" "A" resends the "VTODO" calendar component. "A" sets the
+ overall completion for the to-do at 40%.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VTODO
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b@example.com
+ ATTENDEE;PARTSTAT=COMPLETED;CUTYPE=INDIVIDUAL:mailto:d@example.com
+ DTSTART:19970701T170000Z
+ DUE:19970722T170000Z
+ PRIORITY:1
+ SUMMARY:Create the requirements document
+ UID:calsrv.example.com-873970198738777-00@example.com
+ SEQUENCE:1
+ DTSTAMP:19970718T100000Z
+ STATUS:IN-PROCESS
+ PERCENT-COMPLETE:40
+ END:VTODO
+ END:VCALENDAR
+
+4.5.7. Recurring VTODOs
+
+ The following examples relate to recurring "VTODO" calendar
+ components.
+
+4.5.7.1. Request for a Recurring VTODO
+
+ In this example, "A" sends a recurring "VTODO" calendar component to
+ "B" and "D".
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VTODO
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR:mailto:a@example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com
+ RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
+ DTSTART:19980101T100000Z
+ DUE:19980103T100000Z
+
+
+
+Daboo Standards Track [Page 112]
+
+RFC 5546 iTIP December 2009
+
+
+ SUMMARY:Send Status Reports to Area Managers
+ UID:calsrv.example.com-873970198738777-00@example.com
+ SEQUENCE:0
+ DTSTAMP:19970717T200000Z
+ STATUS:NEEDS-ACTION
+ PRIORITY:1
+ END:VTODO
+ END:VCALENDAR
+
+4.5.7.2. Replying to an Instance of a Recurring VTODO
+
+ In this example, "B" updates "A" on a single instance of the "VTODO"
+ calendar component.
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VTODO
+ ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com
+ PERCENT-COMPLETE:75
+ UID:calsrv.example.com-873970198738777-00@example.com
+ DTSTAMP:19970717T233000Z
+ RECURRENCE-ID:19980101T170000Z
+ SEQUENCE:1
+ END:VTODO
+ END:VCALENDAR
+
+4.6. Journal Examples
+
+ The iCalendar object below describes a single journal entry for
+ October 2, 1997. The "RELATED-TO" property references the phone
+ conference event for which minutes were taken.
+
+ BEGIN:VCALENDAR
+ METHOD:PUBLISH
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VJOURNAL
+ DTSTART:19971002T200000Z
+ DTSTAMP:19970717T233100Z
+ ORGANIZER:mailto:a@example.com
+ SUMMARY:Phone conference minutes
+ DESCRIPTION:The editors meeting was held on October 1, 1997.
+ Details are in the attached document.
+ UID:0981234-1234234-2410@example.com
+ RELATED-TO:0981234-1234234-2402-35@example.com
+ ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt
+
+
+
+Daboo Standards Track [Page 113]
+
+RFC 5546 iTIP December 2009
+
+
+ END:VJOURNAL
+ END:VCALENDAR
+
+4.7. Other Examples
+
+4.7.1. Event Refresh
+
+ Refresh the event with a "UID" property value of
+ "guid-1-12345@example.com":
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REFRESH
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ ATTENDEE:mailto:c@example.com
+ ATTENDEE:mailto:d@example.com
+ UID:guid-1-12345@example.com
+ DTSTAMP:19970603T094000
+ END:VEVENT
+ END:VCALENDAR
+
+4.7.2. Bad RECURRENCE-ID
+
+ Component instances are identified by the combination of "UID",
+ "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends an iTIP
+ message to an "Attendee", there are three cases in which an instance
+ cannot be found. They are:
+
+ 1. The component with the referenced "UID" and "RECURRENCE-ID" has
+ been found but the "SEQUENCE" number in the calendar store does
+ not match that of the iTIP message.
+
+ 2. The component with the referenced "UID" has been found, the
+ "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
+ found.
+
+ 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not
+ support recurrences.
+
+ In case (1), two things can happen. If the "SEQUENCE" number of the
+ "Attendee's" instance is larger than that in the "Organizer's"
+ message, then the "Attendee" is receiving an out-of-sequence message
+ and MUST ignore it. If the "SEQUENCE" number of the "Attendee's"
+ instance is smaller, then the "Organizer" is sending out a newer
+
+
+
+Daboo Standards Track [Page 114]
+
+RFC 5546 iTIP December 2009
+
+
+ version of the component and the "Attendee's" version needs to be
+ updated. Since one or more updates have been missed, the "Attendee"
+ SHOULD send a "REFRESH" message to the "Organizer" to get an updated
+ version of the event.
+
+ In case (2), something has gone wrong. Both the "Organizer" and the
+ "Attendee" should have the same instances, but the "Attendee" does
+ not have the referenced instance. In this case, the "Attendee"
+ SHOULD send a "REFRESH" to the "Organizer" to get an updated version
+ of the event.
+
+ In case (3), the limitations of the "Attendee's" CUA makes it
+ impossible to match an instance other than the single instance
+ scheduled. In this case, the "Attendee" need not send a "REFRESH" to
+ the "Organizer".
+
+ The example below shows a sequence in which an "Attendee" sends a
+ "REFRESH" to the "Organizer".
+
+ +-------------------------+--------------------+--------------------+
+ | Action | Organizer | Attendee |
+ +-------------------------+--------------------+--------------------+
+ | Update an instance | "A" sends REQUEST | |
+ | request | message to "B". | |
+ | | | |
+ | Attendee requests | | "B" sends a |
+ | refresh because | | REFRESH message to |
+ | RECURRENCE-ID was not | | "A". |
+ | found | | |
+ | | | |
+ | Refresh the entire | "A" sends the | |
+ | event | latest copy of the | |
+ | | event to "B" | |
+ | | | |
+ | Attendee handles the | | "B" updates to the |
+ | request and updates the | | latest copy of the |
+ | instance | | meeting. |
+ +-------------------------+--------------------+--------------------+
+
+ Request from "A":
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:example-12345@example.com
+ SEQUENCE:3
+
+
+
+Daboo Standards Track [Page 115]
+
+RFC 5546 iTIP December 2009
+
+
+ RRULE:FREQ=WEEKLY
+ RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ DESCRIPTION:IETF-C&S Conference Call
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970801T210000Z
+ DTEND:19970801T220000Z
+ RECURRENCE-ID:19970809T210000Z
+ DTSTAMP:19970726T083000
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ "B" has the event with "UID" property "example-12345@example.com",
+ but "B's" "SEQUENCE" property value is "1" and the event does not
+ have an instance at the specified recurrence time. This means that
+ "B" has missed at least one update and needs a new copy of the event.
+ "B" requests the latest copy of the event with the following refresh
+ message:
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REFRESH
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a@example.com
+ ATTENDEE:mailto:b@example.com
+ UID:example-12345@example.com
+ DTSTAMP:19970603T094000
+ END:VEVENT
+ END:VCALENDAR
+
+5. Application Protocol Fallbacks
+
+5.1. Partial Implementation
+
+ Applications that support this specification are not required to
+ support the entire protocol. The following describes how methods and
+ properties SHOULD "fallback" in applications that do not support the
+ complete protocol. If a method or property is not addressed in this
+ section, it may be ignored.
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 116]
+
+RFC 5546 iTIP December 2009
+
+
+5.1.1. Event-Related Fallbacks
+
+ +----------------+--------------------------------------------------+
+ | Method | Fallback |
+ +----------------+--------------------------------------------------+
+ | PUBLISH | Required |
+ | REQUEST | PUBLISH |
+ | REPLY | Required |
+ | ADD | Required if recurrences supported; otherwise, |
+ | | reply with a REQUEST-STATUS "2.8; Success, |
+ | | repeating event ignored. Scheduled as a single |
+ | | component", and schedule as a single component. |
+ | CANCEL | Required |
+ | REFRESH | Required |
+ | COUNTER | Reply with "Not Supported". |
+ | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs; |
+ | | otherwise, reply with "Not Supported". |
+ +----------------+--------------------------------------------------+
+
+ +-----------------+-------------------------------------------------+
+ | iCalendar | Fallback |
+ | Property | |
+ +-----------------+-------------------------------------------------+
+ | CALSCALE | Ignore - assume GREGORIAN. |
+ | PRODID | Ignore |
+ | METHOD | Required as described in the Method list above. |
+ | VERSION | Ignore |
+ +-----------------+-------------------------------------------------+
+
+ +-----------------+-------------------------------------------------+
+ | Event-Related | Fallback |
+ | Components | |
+ +-----------------+-------------------------------------------------+
+ | VALARM | Reply with "Not Supported". |
+ | VTIMEZONE | Required if any DateTime value refers to a time |
+ | | zone. |
+ +-----------------+-------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 117]
+
+RFC 5546 iTIP December 2009
+
+
+ +-----------------+-------------------------------------------------+
+ | Component | Fallback |
+ | Property | |
+ +-----------------+-------------------------------------------------+
+ | ATTACH | Ignore |
+ | ATTENDEE | Required if METHOD is REQUEST; otherwise, |
+ | | ignore. |
+ | CATEGORIES | Ignore |
+ | CLASS | Ignore |
+ | COMMENT | Ignore |
+ | COMPLETED | Ignore |
+ | CONTACT | Ignore |
+ | CREATED | Ignore |
+ | DESCRIPTION | Ignore |
+ | DURATION | Required |
+ | DTSTAMP | Required |
+ | DTSTART | Required |
+ | DTEND | Required |
+ | EXDATE | Ignore |
+ | GEO | Ignore |
+ | LAST-MODIFIED | Ignore |
+ | LOCATION | Required |
+ | ORGANIZER | Required if METHOD is REQUEST; otherwise, |
+ | | ignore. |
+ | PRIORITY | Ignore |
+ | RELATED-TO | Ignore |
+ | RDATE | Ignore |
+ | RRULE | Ignore - assume the first instance occurs on |
+ | | the DTSTART property. If implemented, |
+ | | VTIMEZONE MUST also be implemented. |
+ | RECURRENCE-ID | Required if RRULE is implemented; otherwise, |
+ | | ignore. |
+ | REQUEST-STATUS | Required |
+ | RESOURCES | Ignore |
+ | SEQUENCE | Required |
+ | STATUS | Ignore |
+ | SUMMARY | Ignore |
+ | TRANSP | Required if FREEBUSY is implemented; otherwise, |
+ | | ignore. |
+ | URL | Ignore |
+ | UID | Required |
+ | X- | Ignore |
+ +-----------------+-------------------------------------------------+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 118]
+
+RFC 5546 iTIP December 2009
+
+
+5.1.2. Free/Busy-Related Fallbacks
+
+ +---------+---------------------------------------------------------+
+ | Method | Fallback |
+ +---------+---------------------------------------------------------+
+ | PUBLISH | Required if freebusy lookups are supported; otherwise, |
+ | | reply with a REQUEST-STATUS "3.14; Unsupported |
+ | | capability". |
+ | REQUEST | Required if freebusy lookups are supported; otherwise, |
+ | | reply with a REQUEST-STATUS "3.14; Unsupported |
+ | | capability". |
+ | REPLY | Required if freebusy lookups are supported; otherwise, |
+ | | reply with a REQUEST-STATUS "3.14; Unsupported |
+ | | capability". |
+ +---------+---------------------------------------------------------+
+
+ +-----------------+-------------------------------------------------+
+ | iCalendar | Fallback |
+ | Property | |
+ +-----------------+-------------------------------------------------+
+ | CALSCALE | Ignore - assume GREGORIAN. |
+ | PRODID | Ignore |
+ | METHOD | Required as described in the Method list above. |
+ | VERSION | Ignore |
+ +-----------------+-------------------------------------------------+
+
+ +-----------------+-------------------------------------------------+
+ | Component | Fallback |
+ | Property | |
+ +-----------------+-------------------------------------------------+
+ | ATTENDEE | Required if METHOD is REQUEST; otherwise, |
+ | | ignore. |
+ | COMMENT | Ignore |
+ | CONTACT | Ignore |
+ | DTEND | Required |
+ | DTSTAMP | Required |
+ | DTSTART | Required |
+ | DURATION | Ignore |
+ | FREEBUSY | Required |
+ | ORGANIZER | Required if METHOD is REQUEST; otherwise, |
+ | | ignore. |
+ | REQUEST-STATUS | Ignore |
+ | UID | Required |
+ | URL | Ignore |
+ | X- | Ignore |
+ +-----------------+-------------------------------------------------+
+
+
+
+
+
+Daboo Standards Track [Page 119]
+
+RFC 5546 iTIP December 2009
+
+
+5.1.3. To-Do-Related Fallbacks
+
+ +----------------+--------------------------------------------------+
+ | Method | Fallback |
+ +----------------+--------------------------------------------------+
+ | PUBLISH | Required |
+ | REQUEST | PUBLISH |
+ | REPLY | Required |
+ | ADD | Required if recurrences supported; otherwise, |
+ | | reply with a REQUEST-STATUS "2.8; Success, |
+ | | repeating event ignored. Scheduled as a single |
+ | | component", and schedule as a single component. |
+ | CANCEL | Required |
+ | REFRESH | Required |
+ | COUNTER | Reply with "Not Supported". |
+ | DECLINECOUNTER | Required if COUNTER for VTODOs is implemented; |
+ | | otherwise, reply with "Not Supported". |
+ +----------------+--------------------------------------------------+
+
+ +-----------------+-------------------------------------------------+
+ | iCalendar | Fallback |
+ | Property | |
+ +-----------------+-------------------------------------------------+
+ | CALSCALE | Ignore - assume GREGORIAN. |
+ | PRODID | Ignore |
+ | METHOD | Required as described in the Method list above. |
+ | VERSION | Ignore |
+ +-----------------+-------------------------------------------------+
+
+ +-----------------+-------------------------------------------------+
+ | To-Do-Related | Fallback |
+ | Components | |
+ +-----------------+-------------------------------------------------+
+ | VALARM | Reply with "Not Supported". |
+ | VTIMEZONE | Required if any DateTime value refers to a time |
+ | | zone. |
+ +-----------------+-------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 120]
+
+RFC 5546 iTIP December 2009
+
+
+ +------------------+------------------------------------------------+
+ | Component | Fallback |
+ | Property | |
+ +------------------+------------------------------------------------+
+ | ATTACH | Ignore |
+ | ATTENDEE | Required if METHOD is REQUEST; otherwise, |
+ | | ignore. |
+ | CATEGORIES | Ignore |
+ | CLASS | Ignore |
+ | COMMENT | Ignore |
+ | COMPLETED | Required |
+ | CONTACT | Ignore |
+ | CREATED | Ignore |
+ | DESCRIPTION | Required if METHOD is REQUEST; otherwise, |
+ | | ignore. |
+ | DUE | Required |
+ | DURATION | Required |
+ | DTSTAMP | Required |
+ | DTSTART | Required |
+ | EXDATE | Ignore - reply with "Not Supported". |
+ | LAST-MODIFIED | Ignore |
+ | LOCATION | Ignore |
+ | ORGANIZER | Required if METHOD is REQUEST; otherwise, |
+ | | ignore. |
+ | PERCENT-COMPLETE | Ignore |
+ | PRIORITY | Required |
+ | RECURRENCE-ID | Required if RRULE is implemented; otherwise, |
+ | | ignore. |
+ | RELATED-TO | Ignore |
+ | REQUEST-STATUS | Ignore |
+ | RDATE | Ignore |
+ | RRULE | Ignore - assume the first instance occurs on |
+ | | the DTSTART property. If implemented, |
+ | | VTIMEZONE MUST also be implemented. |
+ | RESOURCES | Ignore |
+ | SEQUENCE | Required |
+ | STATUS | Required |
+ | SUMMARY | Ignore |
+ | URL | Ignore |
+ | UID | Required |
+ | X- | Ignore |
+ +------------------+------------------------------------------------+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 121]
+
+RFC 5546 iTIP December 2009
+
+
+5.1.4. Journal-Related Fallbacks
+
+ +---------+---------------------------------------------------------+
+ | Method | Fallback |
+ +---------+---------------------------------------------------------+
+ | PUBLISH | Implementations MAY ignore the METHOD type. The |
+ | | REQUEST-STATUS "3.14; Unsupported capability" MUST be |
+ | | returned. |
+ | ADD | Implementations MAY ignore the METHOD type. The |
+ | | REQUEST-STATUS "3.14; Unsupported capability" MUST be |
+ | | returned. |
+ | CANCEL | Implementations MAY ignore the METHOD type. The |
+ | | REQUEST-STATUS "3.14; Unsupported capability" MUST be |
+ | | returned. |
+ +---------+---------------------------------------------------------+
+
+ +-----------------+-------------------------------------------------+
+ | iCalendar | Fallback |
+ | Property | |
+ +-----------------+-------------------------------------------------+
+ | CALSCALE | Ignore - assume GREGORIAN. |
+ | PRODID | Ignore |
+ | METHOD | Required as described in the Method list above. |
+ | VERSION | Ignore |
+ +-----------------+-------------------------------------------------+
+
+ +-----------------+-------------------------------------------------+
+ | Journal-Related | Fallback |
+ | Components | |
+ +-----------------+-------------------------------------------------+
+ | VTIMEZONE | Required if any DateTime value refers to a time |
+ | | zone. |
+ +-----------------+-------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 122]
+
+RFC 5546 iTIP December 2009
+
+
+ +-----------------+-------------------------------------------------+
+ | Component | Fallback |
+ | Property | |
+ +-----------------+-------------------------------------------------+
+ | ATTACH | Ignore |
+ | ATTENDEE | Ignore |
+ | CATEGORIES | Ignore |
+ | CLASS | Ignore |
+ | COMMENT | Ignore |
+ | CONTACT | Ignore |
+ | CREATED | Ignore |
+ | DESCRIPTION | Ignore |
+ | DTSTAMP | Required |
+ | DTSTART | Required |
+ | EXDATE | Ignore |
+ | LAST-MODIFIED | Ignore |
+ | ORGANIZER | Ignore |
+ | RECURRENCE-ID | Required if RRULE is implemented; otherwise, |
+ | | ignore. |
+ | RELATED-TO | Ignore |
+ | RDATE | Ignore |
+ | RRULE | Ignore - assume the first instance occurs on |
+ | | the DTSTART property. If implemented, |
+ | | VTIMEZONE MUST also be implemented. |
+ | SEQUENCE | Required |
+ | STATUS | Ignore |
+ | SUMMARY | Required |
+ | URL | Ignore |
+ | UID | Required |
+ | X- | Ignore |
+ +-----------------+-------------------------------------------------+
+
+5.2. Latency Issues
+
+ With a store-and-forward transport, it is possible for events to
+ arrive out of sequence. That is, a "CANCEL" method may be received
+ prior to receiving the associated "REQUEST" for the calendar
+ component. This section discusses a few of these scenarios.
+
+5.2.1. Cancellation of an Unknown Calendar Component
+
+ When a "CANCEL" method is received before the original "REQUEST"
+ method, the calendar will be unable to correlate the "UID" property
+ of the cancellation with an existing calendar component. It is
+ suggested that messages that cannot be correlated and that also
+ contain non-zero sequence numbers be held and not discarded.
+ Implementations MAY age them out if no other messages arrive with the
+ same "UID" property value and a lower sequence number.
+
+
+
+Daboo Standards Track [Page 123]
+
+RFC 5546 iTIP December 2009
+
+
+5.2.2. Unexpected Reply from an Unknown Delegate
+
+ When an "Attendee" delegates an item to another CU, they MUST send a
+ "REPLY" method to the "Organizer" using the "ATTENDEE" properties to
+ indicate that the request was delegated and to whom. Hence, it is
+ possible for an "Organizer" to receive a "REPLY" from a CU not listed
+ as one of the original "Attendees". The resolution is left to the
+ implementation, but it is expected that the calendaring software will
+ either accept the reply or hold it until the related "REPLY" method
+ is received from the "Delegator". If the version of the "REPLY"
+ method is out of date, the "Organizer" SHOULD treat the message as a
+ "REFRESH" message and update the "Delegate" with the correct version,
+ provided that delegation to that delegate is acceptable.
+
+5.3. Sequence Number
+
+ Under some conditions, a CUA may receive requests and replies with
+ the same "SEQUENCE" property value. The "DTSTAMP" property is
+ utilized as a tie-breaker when two items with the same "SEQUENCE"
+ property value are evaluated.
+
+6. Security Considerations
+
+ iTIP is an abstract transport protocol that will be bound to a real-
+ time transport, a store-and-forward transport, and perhaps other
+ transports. The transport protocol will be responsible for providing
+ facilities for authentication and encryption using standard Internet
+ mechanisms that are mutually understood between the sender and
+ receiver.
+
+6.1. Security Threats
+
+6.1.1. Spoofing the Organizer
+
+ In iTIP, the "Organizer" (or someone working on the "Organizer's"
+ behalf) is the only person authorized to make changes to an existing
+ "VEVENT", "VTODO", or "VJOURNAL" calendar component and republish it
+ or redistribute updates to the "Attendees". An iCalendar object that
+ maliciously changes or cancels an existing "VEVENT", "VTODO", or
+ "VJOURNAL" calendar component may be constructed by someone other
+ than the "Organizer" and republished or sent to the "Attendees".
+
+6.1.2. Spoofing the Attendee
+
+ In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component
+ (or someone working on the "Attendee's" behalf) is the only person
+ authorized to update any parameter associated with their "ATTENDEE"
+
+
+
+
+Daboo Standards Track [Page 124]
+
+RFC 5546 iTIP December 2009
+
+
+ property and send it to the "Organizer". An iCalendar object that
+ maliciously changes the "ATTENDEE" parameters may be constructed by
+ someone other than the real "Attendee" and sent to the "Organizer".
+
+6.1.3. Unauthorized Replacement of the Organizer
+
+ There will be circumstances when "Attendees" of an event or to-do
+ decide, using out-of-band mechanisms, that the "Organizer" must be
+ replaced. When the new "Organizer" sends out the updated "VEVENT" or
+ "VTODO", the "Attendee's" CUA will detect that the "Organizer" has
+ been changed, but it has no way of knowing whether or not the change
+ was mutually agreed upon.
+
+6.1.4. Eavesdropping and Data Integrity
+
+ The iCalendar object is constructed with human-readable clear text.
+ Any information contained in an iCalendar object may be read and/or
+ changed by unauthorized persons while the object is in transit.
+
+6.1.5. Flooding a Calendar
+
+ Implementations could provide a means to automatically incorporate
+ "REQUEST" methods into a calendar. This presents the opportunity for
+ a calendar to be flooded with requests, which effectively blocks all
+ the calendar's free time.
+
+6.1.6. Unauthorized REFRESH Requests
+
+ It is possible for an "Organizer" to receive a "REFRESH" request from
+ someone who is not an "Attendee" of an event or to-do. Only
+ "Attendees" of an event or to-do are authorized to receive replies to
+ "REFRESH" requests. Replying to such requests to anyone who is not
+ an "Attendee" may be a security problem.
+
+6.2. Recommendations
+
+ For an application where the information is sensitive or critical and
+ the network is subject to a high probability of attack, iTIP
+ transactions SHOULD be encrypted and authenticated. This helps
+ mitigate the threats of spoofing, eavesdropping, and malicious
+ changes in transit.
+
+6.2.1. Securing iTIP transactions
+
+ iTIP transport bindings MUST provide a mechanism to enable
+ authentication of the sender's identity as well as privacy and
+ integrity of the data being transmitted. This allows the receiver of
+ a signed iCalendar object to verify the identity of the sender. This
+
+
+
+Daboo Standards Track [Page 125]
+
+RFC 5546 iTIP December 2009
+
+
+ sender may then be correlated to an "ATTENDEE" property in the
+ iCalendar object. If the correlation is made and the sender is
+ authorized to make the requested change or update, then the operation
+ may proceed. It also allows the message to be encrypted to prevent
+ unauthorized reading of the message contents in transit. iTIP
+ transport binding documents describe this process in detail.
+
+6.2.2. Implementation Controls
+
+ The threat of unauthorized replacement of the "Organizer" SHOULD be
+ mitigated by a calendar system that uses this protocol by providing
+ controls or alerts that make "Calendar Users" aware of such
+ "Organizer" changes and allowing them to decide whether or not the
+ request should be honored.
+
+ The threat of flooding a calendar SHOULD be mitigated by a calendar
+ system that uses this protocol by providing controls that may be used
+ to limit the acceptable sources for iTIP transactions, and perhaps
+ the size of messages and volume of traffic, by source.
+
+ The threat of unauthorized "REFRESH" requests SHOULD be mitigated by
+ a calendar system that uses this protocol by providing controls or
+ alerts that allow "Calendar Users" to decide whether or not the
+ request should be honored. An implementation MAY decide to maintain,
+ for audit or historical purposes, "Calendar Users" who were part of
+ an "Attendee" list and who were subsequently uninvited. Similar
+ controls or alerts should be provided when a "REFRESH" request is
+ received from these "Calendar Users" as well.
+
+6.2.3. Access Controls and Filtering
+
+ In many environments, there could be restrictions on who is allowed
+ to schedule with whom and who the allowed delegates are for
+ particular "Calendar Users".
+
+ iTIP transport bindings SHOULD provide mechanisms for implementing
+ access controls or filtering to ensure iTIP transactions only take
+ place between authorized "Calendar Users". That would include
+ preventing one "Calendar User" from scheduling with another or one
+ "Calendar User" delegating to another.
+
+6.3. Privacy Issues
+
+ The "Organizer" might want to keep "Attendees" from knowing which
+ other "Attendees" are participating in an event or to-do. The
+ "Organizer" has the choice of sending single iTIP messages with a
+ full list of "Attendees" or sending iTIP messages to each "Attendee"
+ with only that "Attendee" listed.
+
+
+
+Daboo Standards Track [Page 126]
+
+RFC 5546 iTIP December 2009
+
+
+7. IANA Considerations
+
+7.1. Registration Template for REQUEST-STATUS Values
+
+ This specification updates [RFC5545] by adding a "REQUEST-STATUS"
+ value registry to the iCalendar Elements registry.
+
+ A "REQUEST-STATUS" value is defined by completing the following
+ template.
+
+ Status Code: Hierarchical, numeric return status code, following
+ the rules defined in Section 3.8.8.3 of [RFC5545].
+
+ Status Description: Textual status description. A short but
+ clear description of the error.
+
+ Status Exception Data: Textual exception data. A short but clear
+ description of what might appear in this field.
+
+ Description: Describe the underlying cause for this status code
+ value.
+
+7.2. Additions to iCalendar METHOD Registry
+
+ This document defines the following values for the iCalendar "METHOD"
+ property, using the values template from Section 8.2.6 of [RFC5545].
+ These should be added to the Methods Registry defined in Section
+ 8.3.12 of [RFC5545]:
+
+7.2.1. METHOD:PUBLISH
+
+ Value: PUBLISH
+
+ Purpose: Standard iTIP "METHOD" value.
+
+ Conformance: Only used with the "METHOD" property.
+
+ Examples: See this RFC.
+
+7.2.2. METHOD:REQUEST
+
+ Value: REQUEST
+
+ Purpose: Standard iTIP "METHOD" value.
+
+ Conformance: Only used with the "METHOD" property.
+
+ Examples: See this RFC.
+
+
+
+Daboo Standards Track [Page 127]
+
+RFC 5546 iTIP December 2009
+
+
+7.2.3. METHOD:REPLY
+
+ Value: REPLY
+
+ Purpose: Standard iTIP "METHOD" value.
+
+ Conformance: Only used with the "METHOD" property.
+
+ Examples: See this RFC.
+
+7.2.4. METHOD:ADD
+
+ Value: ADD
+
+ Purpose: Standard iTIP "METHOD" value.
+
+ Conformance: Only used with the "METHOD" property.
+
+ Examples: See this RFC.
+
+7.2.5. METHOD:CANCEL
+
+ Value: CANCEL
+
+ Purpose: Standard iTIP "METHOD" value.
+
+ Conformance: Only used with the "METHOD" property.
+
+ Examples: See this RFC.
+
+7.2.6. METHOD:REFRESH
+
+ Value: REFRESH
+
+ Purpose: Standard iTIP "METHOD" value.
+
+ Conformance: Only used with the "METHOD" property.
+
+ Examples: See this RFC.
+
+7.2.7. METHOD:COUNTER
+
+ Value: COUNTER
+
+ Purpose: Standard iTIP "METHOD" value.
+
+ Conformance: Only used with the "METHOD" property.
+
+
+
+
+Daboo Standards Track [Page 128]
+
+RFC 5546 iTIP December 2009
+
+
+ Examples: See this RFC.
+
+7.2.8. METHOD:DECLINECOUNTER
+
+ Value: DECLINECOUNTER
+
+ Purpose: Standard iTIP "METHOD" value.
+
+ Conformance: Only used with the "METHOD" property.
+
+ Examples: See this RFC.
+
+7.3. REQUEST-STATUS Value Registry
+
+ New "REQUEST-STATUS" values can be registered using the process
+ described in Section 8.2.1 of [RFC5545].
+
+ The following table is to be used to initialize the "REQUEST-STATUS"
+ value registry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 129]
+
+RFC 5546 iTIP December 2009
+
+
+ +-------------+---------+--------------------------+
+ | Status Code | Status | Reference |
+ +-------------+---------+--------------------------+
+ | 2.0 | Current | RFC 5546, Section 3.6.1 |
+ | 2.1 | Current | RFC 5546, Section 3.6.2 |
+ | 2.2 | Current | RFC 5546, Section 3.6.3 |
+ | 2.3 | Current | RFC 5546, Section 3.6.4 |
+ | 2.4 | Current | RFC 5546, Section 3.6.5 |
+ | 2.5 | Current | RFC 5546, Section 3.6.6 |
+ | 2.6 | Current | RFC 5546, Section 3.6.7 |
+ | 2.7 | Current | RFC 5546, Section 3.6.8 |
+ | 2.8 | Current | RFC 5546, Section 3.6.9 |
+ | 2.9 | Current | RFC 5546, Section 3.6.10 |
+ | 2.10 | Current | RFC 5546, Section 3.6.11 |
+ | 2.11 | Current | RFC 5546, Section 3.6.12 |
+ | 3.0 | Current | RFC 5546, Section 3.6.13 |
+ | 3.1 | Current | RFC 5546, Section 3.6.14 |
+ | 3.2 | Current | RFC 5546, Section 3.6.15 |
+ | 3.3 | Current | RFC 5546, Section 3.6.16 |
+ | 3.4 | Current | RFC 5546, Section 3.6.17 |
+ | 3.5 | Current | RFC 5546, Section 3.6.18 |
+ | 3.6 | Current | RFC 5546, Section 3.6.19 |
+ | 3.7 | Current | RFC 5546, Section 3.6.20 |
+ | 3.8 | Current | RFC 5546, Section 3.6.21 |
+ | 3.9 | Current | RFC 5546, Section 3.6.22 |
+ | 3.10 | Current | RFC 5546, Section 3.6.23 |
+ | 3.11 | Current | RFC 5546, Section 3.6.24 |
+ | 3.12 | Current | RFC 5546, Section 3.6.25 |
+ | 3.13 | Current | RFC 5546, Section 3.6.26 |
+ | 3.14 | Current | RFC 5546, Section 3.6.27 |
+ | 4.0 | Current | RFC 5546, Section 3.6.28 |
+ | 5.0 | Current | RFC 5546, Section 3.6.29 |
+ | 5.1 | Current | RFC 5546, Section 3.6.30 |
+ | 5.2 | Current | RFC 5546, Section 3.6.31 |
+ | 5.3 | Current | RFC 5546, Section 3.6.32 |
+ +-------------+---------+--------------------------+
+
+8. Acknowledgments
+
+ This is an update to the original iTIP document authored by S.
+ Silverberg, S. Mansour, F. Dawson, and R. Hopson.
+
+ This revision is the product of the Calsify IETF Working Group, and
+ several participants have made important contributions to this
+ specification, including Oliver Block, Bernard Desruisseaux, Mike
+ Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot
+ Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg
+ II, Robert Ransdell, and Caleb Richardson.
+
+
+
+Daboo Standards Track [Page 130]
+
+RFC 5546 iTIP December 2009
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
+ URL scheme", RFC 2368, July 1998.
+
+ [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
+ Core Object Specification (iCalendar)", RFC 5545,
+ September 2009.
+
+9.2. Informative References
+
+ [iMIP] Melnikov, A., Ed., "iCalendar Message-Based
+ Interoperability Protocol (iMIP)", Work in Progress,
+ October 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 131]
+
+RFC 5546 iTIP December 2009
+
+
+Appendix A. Differences from RFC 2446
+
+A.1. Changed Restrictions
+
+ This specification now defines an allowed combination of "REQUEST-
+ STATUS" codes when multiple iCalendar components are included in an
+ iTIP message.
+
+ This specification now restricts "RECURRENCE-ID" to only a single
+ occurrence in any one iCalendar component in an iTIP message, as
+ required by [RFC5545].
+
+ Changed the "RECURRENCE-ID" entry in the component restriction table
+ to "0 or 1" from "0+", to fall in line with [RFC5545].
+
+ Changed the "FREEBUSY" entry in the "VFREEBUSY", "PUBLISH", and
+ "REPLY" restriction tables to "0+" from "1+", to fall in line with
+ [RFC5545].
+
+ Changed the "FREEBUSY" description in the "VFREEBUSY" and "REPLY"
+ restriction tables to indicate that different "FBTYPE" ranges MUST
+ NOT overlap.
+
+ Changed the "TZNAME" entry in the "VTIMEZONE" restriction table to
+ "0+" from "0 or 1", to fall in line with [RFC5545].
+
+ Changed the "COMMENT" entry in the component restriction tables to
+ "0+" from "0 or 1", to fall in line with [RFC5545].
+
+ Added the "ATTENDEE" entry in the "VALARM" restriction table to match
+ the email alarm type in [RFC5545].
+
+ Changed the "CATEGORIES" entry in the component restriction tables to
+ "0+" from "0 or 1", to fall in line with [RFC5545].
+
+ Changed the "RESOURCES" entry in the component restriction tables to
+ "0+" from "0 or 1", to fall in line with [RFC5545].
+
+ Changed the "CONTACT" entry in the "VFREEBUSY" restriction table to
+ "0 or 1" from "0+", to fall in line with [RFC5545].
+
+ Changed the "UID" entry in the "VFREEBUSY" and "PUBLISH" restriction
+ tables to "1" from "0", to fall in line with [RFC5545].
+
+ Added the "COMPLETED" entry in the "VTODO" restriction tables to fall
+ in line with [RFC5545].
+
+
+
+
+
+Daboo Standards Track [Page 132]
+
+RFC 5546 iTIP December 2009
+
+
+ Added the "REQUEST-STATUS" entry in the "VJOURNAL" restriction tables
+ to fall in line with [RFC5545].
+
+A.2. Deprecated Features
+
+ The "EXRULE" property was removed in [RFC5545] and references to that
+ have been removed in this document too.
+
+ The "PROCEDURE" value for the "ACTION" property was removed in
+ [RFC5545] and references to that have been removed in this document
+ too.
+
+ The "THISANDPRIOR" option for the "RANGE" parameter was removed in
+ [RFC5545] and references to that have been removed in this document
+ too.
+
+Author's Address
+
+ Cyrus Daboo (editor)
+ Apple Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+ USA
+
+ EMail: cyrus@daboo.name
+ URI: http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 133]
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 18:29:57 +0000