diff options
Diffstat (limited to 'vendor/sabre/dav/docs/rfc5546.txt')
| -rw-r--r-- | vendor/sabre/dav/docs/rfc5546.txt | 7451 |
1 files changed, 0 insertions, 7451 deletions
diff --git a/vendor/sabre/dav/docs/rfc5546.txt b/vendor/sabre/dav/docs/rfc5546.txt deleted file mode 100644 index 80361d81a..000000000 --- a/vendor/sabre/dav/docs/rfc5546.txt +++ /dev/null @@ -1,7451 +0,0 @@ - - - - - - -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] - |