From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5546.txt | 7451 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 7451 insertions(+) create mode 100644 doc/rfc/rfc5546.txt (limited to 'doc/rfc/rfc5546.txt') diff --git a/doc/rfc/rfc5546.txt b/doc/rfc/rfc5546.txt new file mode 100644 index 0000000..80361d8 --- /dev/null +++ b/doc/rfc/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] + -- cgit v1.2.3