mirror of
https://git.friendi.ca/friendica/friendica-addons.git
synced 2024-09-11 14:45:12 +00:00
7452 lines
311 KiB
Text
7452 lines
311 KiB
Text
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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]
|
|||
|
|