[CalendarServer-changes] [5538] CalendarServer/trunk/doc/RFC
source_changes at macosforge.org
source_changes at macosforge.org
Tue Apr 27 13:51:52 PDT 2010
Revision: 5538
http://trac.macosforge.org/projects/calendarserver/changeset/5538
Author: cdaboo at apple.com
Date: 2010-04-27 13:51:51 -0700 (Tue, 27 Apr 2010)
Log Message:
-----------
iTIP has been updated.
Added Paths:
-----------
CalendarServer/trunk/doc/RFC/rfc5546-iTIP.txt
Removed Paths:
-------------
CalendarServer/trunk/doc/RFC/rfc2446-iTIP.txt
Deleted: CalendarServer/trunk/doc/RFC/rfc2446-iTIP.txt
===================================================================
--- CalendarServer/trunk/doc/RFC/rfc2446-iTIP.txt 2010-04-27 20:50:51 UTC (rev 5537)
+++ CalendarServer/trunk/doc/RFC/rfc2446-iTIP.txt 2010-04-27 20:51:51 UTC (rev 5538)
@@ -1,6107 +0,0 @@
-
-
-
-
-
-
-Network Working Group S. Silverberg
-Request for Comments: 2446 Microsoft
-Category: Standards Track S. Mansour
- Netscape
- F. Dawson
- Lotus
- R. Hopson
- ON Technologies
- November 1998
-
-
- iCalendar Transport-Independent Interoperability Protocol
- (iTIP)
- Scheduling Events, BusyTime, To-dos and Journal Entries
-
-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) The Internet Society (1998). All Rights Reserved.
-
-Abstract
-
- This document specifies how calendaring systems use iCalendar objects
- to interoperate with other calendar systems. It does so in a general
- way so as to allow multiple methods of communication between systems.
- Subsequent documents specify interoperable methods of communications
- between systems that use this protocol.
-
- The document outlines a model for calendar exchange that defines both
- static and dynamic event, to-do, journal and free/busy objects.
- Static objects are used to transmit information from one entity to
- another without the expectation of continuity or referential
- integrity with the original item. Dynamic objects are a superset of
- static objects and will gracefully degrade to their static
- counterparts for clients that only support static objects.
-
- This document specifies an Internet protocol based on the iCalendar
- object specification that provides scheduling interoperability
- between different calendar systems. The Internet protocol is called
- the "iCalendar Transport-Independent Interoperability Protocol
- (iTIP)".
-
-
-
-Silverberg, et. al. Standards Track [Page 1]
-
-RFC 2446 iTIP November 1998
-
-
- iTIP complements the iCalendar object specification by adding
- semantics for group scheduling methods commonly available in current
- calendar systems. These scheduling methods permit two or more
- calendar systems to perform transactions such as publish, schedule,
- reschedule, respond to scheduling requests, negotiation of changes or
- cancel iCalendar-based calendar components.
-
- iTIP is defined independent of the particular transport used to
- transmit the scheduling information. Companion memos to iTIP provide
- bindings of the interoperability protocol to a number of Internet
- protocols.
-
-Table of Contents
-
- 1 INTRODUCTION...................................................5
- 1.1 FORMATTING CONVENTIONS .....................................5
- 1.2 RELATED DOCUMENTS ..........................................6
- 1.3 ITIP ROLES AND TRANSACTIONS ................................6
- 2 INTEROPERABILITY MODELS........................................8
- 2.1 APPLICATION PROTOCOL .......................................9
- 2.1.1 Calendar Entry State ...................................9
- 2.1.2 Delegation .............................................9
- 2.1.3 Acting on Behalf of other Calendar Users ..............10
- 2.1.4 Component Revisions ...................................10
- 2.1.5 Message Sequencing ....................................11
- 3 APPLICATION PROTOCOL ELEMENTS.................................12
- 3.1 COMMON COMPONENT RESTRICTION TABLES .......................13
- 3.2 METHODS FOR VEVENT CALENDAR COMPONENTS ....................14
- 3.2.1 PUBLISH ...............................................15
- 3.2.2 REQUEST ...............................................17
- 3.2.2.1 Rescheduling an Event..............................19
- 3.2.2.2 Updating or Reconfirmation of an Event.............19
- 3.2.2.3 Delegating an Event to another CU..................19
- 3.2.2.4 Changing the Organizer.............................20
- 3.2.2.5 Sending on Behalf of the Organizer.................20
- 3.2.2.6 Forwarding to An Uninvited CU......................20
- 3.2.2.7 Updating Attendee Status...........................21
- 3.2.3 REPLY .................................................21
- 3.2.4 ADD ...................................................23
- 3.2.5 CANCEL ................................................25
- 3.2.6 REFRESH ...............................................26
- 3.2.7 COUNTER ...............................................28
- 3.2.8 DECLINECOUNTER ........................................29
- 3.3 METHODS FOR VFREEBUSY COMPONENTS ..........................31
- 3.3.1 PUBLISH ...............................................32
- 3.3.2 REQUEST ...............................................33
- 3.3.3 REPLY .................................................34
- 3.4 METHODS FOR VTODO COMPONENTS ..............................35
-
-
-
-Silverberg, et. al. Standards Track [Page 2]
-
-RFC 2446 iTIP November 1998
-
-
- 3.4.1 PUBLISH ...............................................35
- 3.4.2 REQUEST ...............................................37
- 3.4.2.1 REQUEST for Rescheduling a VTODO...................39
- 3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO....39
- 3.4.2.3 REQUEST for Delegating a VTODO.....................40
- 3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User....40
- 3.4.2.5 REQUEST Updated Attendee Status....................41
- 3.4.3 REPLY .................................................41
- 3.4.4 ADD ...................................................43
- 3.4.5 CANCEL ................................................44
- 3.4.6 REFRESH ...............................................46
- 3.4.7 COUNTER ...............................................48
- 3.4.8 DECLINECOUNTER ........................................49
- 3.5 METHODS FOR VJOURNAL COMPONENTS ...........................50
- 3.5.1 PUBLISH ...............................................51
- 3.5.2 ADD ...................................................52
- 3.5.3 CANCEL ................................................53
- 3.6 STATUS REPLIES ............................................55
- 3.7 IMPLEMENTATION CONSIDERATIONS .............................57
- 3.7.1 Working With Recurrence Instances .....................57
- 3.7.2 Attendee Property Considerations ......................58
- 3.7.3 X-Tokens ..............................................59
- 4 EXAMPLES......................................................59
- 4.1 PUBLISHED EVENT EXAMPLES ..................................59
- 4.1.1 A Minimal Published Event .............................60
- 4.1.2 Changing A Published Event ............................60
- 4.1.3 Canceling A Published Event ...........................61
- 4.1.4 A Rich Published Event ................................62
- 4.1.5 Anniversaries or Events attached to entire days .......63
- 4.2 GROUP EVENT EXAMPLES ......................................63
- 4.2.1 A Group Event Request .................................64
- 4.2.2 Reply To A Group Event Request ........................65
- 4.2.3 Update An Event .......................................65
- 4.2.4 Countering an Event Proposal ..........................66
- 4.2.5 Delegating an Event ...................................68
- 4.2.6 Delegate Accepts the Meeting ..........................70
- 4.2.7 Delegate Declines the Meeting .........................71
- 4.2.8 Forwarding an Event Request ...........................72
- 4.2.9 Cancel A Group Event ..................................72
- 4.2.10 Removing Attendees ...................................74
- 4.2.11 Replacing the Organizer ..............................75
- 4.3 BUSY TIME EXAMPLES ........................................76
- 4.3.1 Request Busy Time .....................................77
- 4.3.2 Reply To A Busy Time Request ..........................77
- 4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ....................78
- 4.4.1 A Recurring Event Spanning Time Zones .................78
- 4.4.2 Modify A Recurring Instance ...........................79
- 4.4.3 Cancel an Instance ....................................81
-
-
-
-Silverberg, et. al. Standards Track [Page 3]
-
-RFC 2446 iTIP November 1998
-
-
- 4.4.4 Cancel Recurring Event ................................81
- 4.4.5 Change All Future Instances ...........................82
- 4.4.6 Add A New Instance To A Recurring Event ...............82
- 4.4.7 Add A New Series of Instances To A Recurring Event ....83
- 4.4.8 Counter An Instance Of A Recurring Event ..............87
- 4.4.9 Error Reply To A Request ..............................88
- 4.5 GROUP TO-DO EXAMPLES ......................................89
- 4.5.1 A VTODO Request .......................................90
- 4.5.2 A VTODO Reply .........................................90
- 4.5.3 A VTODO Request for Updated Status ....................91
- 4.5.4 A Reply: Percent-Complete .............................91
- 4.5.5 A Reply: Completed ....................................92
- 4.5.6 An Updated VTODO Request ..............................92
- 4.5.7 Recurring VTODOs ......................................92
- 4.5.7.1 Request for a Recurring VTODO......................93
- 4.5.7.2 Calculating due dates in recurring VTODOs..........93
- 4.5.7.3 Replying to an instance of a recurring VTODO.......93
- 4.6 JOURNAL EXAMPLES ..........................................94
- 4.7 OTHER EXAMPLES ............................................94
- 4.7.1 Event Refresh .........................................94
- 4.7.2 Bad RECURRENCE-ID .....................................95
- 5 APPLICATION PROTOCOL FALLBACKS................................97
- 5.1 PARTIAL IMPLEMENTATION ....................................97
- 5.1.1 Event-Related Fallbacks ...............................97
- 5.1.2 Free/Busy-Related Fallbacks ...........................99
- 5.1.3 To-Do-Related Fallbacks ...............................99
- 5.1.4 Journal-Related Fallbacks ............................101
- 5.2 LATENCY ISSUES ...........................................102
- 5.2.1 Cancellation of an Unknown Calendar Component. .......102
- 5.2.2 Unexpected Reply from an Unknown Delegate ............103
- 5.3 SEQUENCE NUMBER ..........................................103
- 6 SECURITY CONSIDERATIONS......................................103
- 6.1 SECURITY THREATS .........................................103
- 6.1.1 Spoofing the "Organizer" .............................103
- 6.1.2 Spoofing the "Attendee" ..............................103
- 6.1.3 Unauthorized Replacement of the Organizer ............104
- 6.1.4 Eavesdropping ........................................104
- 6.1.5 Flooding a Calendar ..................................104
- 6.1.6 Procedural Alarms ....................................104
- 6.1.7 Unauthorized REFRESH Requests ........................104
- 6.2 RECOMMENDATIONS ..........................................104
- 6.2.1 Use of [RFC-1847] to secure iTIP transactions ........105
- 6.2.2 Implementation Controls ..............................105
- 7 ACKNOWLEDGMENTS..............................................106
- 8 BIBLIOGRAPHY.................................................106
- 9 AUTHORS' ADDRESSES...........................................107
- 10 FULL COPYRIGHT STATEMENT....................................109
-
-
-
-
-Silverberg, et. al. Standards Track [Page 4]
-
-RFC 2446 iTIP November 1998
-
-
-1 Introduction
-
- This document specifies how calendaring systems use iCalendar objects
- to interoperate with other calendar 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 so as to allow multiple
- methods of communication between systems. Subsequent documents
- 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.
-
-1.1 Formatting Conventions
-
- In order to refer to elements of the calendaring and scheduling
- model, core object or interoperability protocol defined in [iCAL] and
- [iTIP] several formatting conventions have been utilized.
-
- 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 [RFC-2119].
-
- 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 defined by [iTIP]. Calendar components
- defined by [iCAL] 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. Scheduling methods defined by [iTIP] 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 [iCAL] 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
-
-
-
-Silverberg, et. al. Standards Track [Page 5]
-
-RFC 2446 iTIP November 1998
-
-
- defined by this memo are referred to with lower case, 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 memo 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 memos that,
- along with this one, describe the Internet calendaring and scheduling
- standards. This document, [iTIP], specifies an interoperability
- protocol for scheduling between different implementations. The
- related documents are:
-
- [iCAL] - 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 memo does not attempt to repeat the specification of concepts or
- definitions from these other memos. Where possible, references are
- made to the memo that provides for the specification of these
- concepts or definitions.
-
-1.3 ITIP Roles and Transactions
-
- ITIP defines methods for exchanging [iCAL] objects for the purposes
- of group calendaring and scheduling between "Calendar Users" (CUs).
- CUs take on one of two roles in iTIP. The CU who initiates an
- exchange takes on the role of "Organizer". For example, the CU who
- proposes a group meeting is the "Organizer". The CUs asked to
- participate in the group meeting by the "Organizer" take on the role
- of "Attendee". Note that "role" is also a descriptive parameter to
- the _ATTENDEE_ property. Its use is to convey descriptive context to
- an "Attendee" such as "chair", "req-participant" or "non-participant"
- and has nothing to do with the calendaring workflow.
-
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 6]
-
-RFC 2446 iTIP November 1998
-
-
- The ITIP methods are listed below and their usage and semantics are
- defined in section 3 of this document.
-
- +================+==================================================+
- | Method | Description |
- |================+==================================================|
- | PUBLISH | Used to publish a calendar entry 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 a calendar entry 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 VTODOs to |
- | | other Calendar Users are all examples. |
- | | Requests are also used by the "Organizer" to |
- | | update the status of a calendar entry. |
- | | |
- | 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 instances to an existing |
- | | VEVENT, VTODO, or VJOURNAL. |
- | | |
- | CANCEL | Cancel one or more instances of an existing |
- | | VEVENT, VTODO, or VJOURNAL. |
- | | |
- | REFRESH | The Refresh method is used by an "Attendee" to |
- | | request the latest version of a calendar entry. |
- | | |
- | COUNTER | The Counter method is used by an "Attendee" to |
- | | negotiate a change in the calendar entry. |
- | | Examples include the request to change a |
- | | proposed Event time or change the due date for a |
- | | VTODO. |
- | | |
- | DECLINE- | Used by the "Organizer" to decline the proposed |
- | COUNTER | counter-proprosal. |
- +================+==================================================+
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 7]
-
-RFC 2446 iTIP November 1998
-
-
- 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.
-
-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.
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 8]
-
-RFC 2446 iTIP November 1998
-
-
- +------------------------------------------+
- | iTIP |
- +------------------------------------------+
- |Real-time | Store-and-Fwd | Other |
- |Transport | Transport | Transports... |
- +------------------------------------------+
-
-2.1 Application Protocol
-
- In the iTIP model, a calendar entry 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 calendar entry. They can, however, use
- the "COUNTER" method to suggest changes to the "Organizer". In any
- case, the "Organizer" has complete control over the master calendar
- entry.
-
-2.1.1 Calendar Entry State
-
- There are two distinct states relevant to calendar entries: the
- overall state of the entry and the state associated with an
- "Attendee" to that entry.
-
- The state of an entry 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 calendar entry.
-
- The state of a particular "Attendee" relative to an entry is defined
- by the "partstat" parameter in the "ATTENDEE" property for each
- "Attendee". When an "Organizer" issues the initial entry, "Attendee"
- status is 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 section.
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 9]
-
-RFC 2446 iTIP November 1998
-
-
-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. The rules for incrementing the
- "SEQUENCE" number are defined in [iCAL]. For clarity, these rules are
- paraphrased here in terms of how they are applied in [iTIP]. For a
- given "UID" in a calendar component:
-
- . For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
- value is incremented according to the rules defined in [iCAL].
-
- . The "SEQUENCE" property value MUST be incremented each time the
- "Organizer" uses the "ADD" or "CANCEL" methods.
-
- . 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.
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 10]
-
-RFC 2446 iTIP November 1998
-
-
- 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 entry that has been revised and allow the CU to
- decide whether or not to accept the response.
-
-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 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" is 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" property value is 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" and "SEQUENCE" properties 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" property values match and
- the "SEQUENCE" property values match, the response with the
- latest "DTSTAMP" overrides all others.
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 11]
-
-RFC 2446 iTIP November 1998
-
-
- Hence, CUAs must persist the following component properties: "UID",
- "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each
- "ATTENDEE" property of a component CUAs must persist the "SEQUENCE"
- and "DTSTAMP" property values associated with the "Attendee's"
- response.
-
-3 Application Protocol Elements
-
- ITIP messages are "text/calendar" MIME entities that contain
- calendaring and scheduling information. The particular type of [iCAL]
- 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
- combinations of calendar components and the method types that this
- memo 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 |
- |Decline- | | | | |
- |Counter | 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 contains "MUST" if the component or
- property must be present, "MAY" if the component or property is
- optional, and "NOT" if the component or property must not be present.
- Entries in the second column sometimes contain comments for further
- clarification.
-
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 12]
-
-RFC 2446 iTIP November 1998
-
-
-3.1 Common Component Restriction Tables
-
- The restriction table below applies to properties of the iCalendar
- object. That is, the properties at the outermost scope. The presence
- column uses the following values to assert whether a property is
- required, is 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 "X-PROPERTY" and "X-COMPONENT" to show
- where vendor-specific properties and components can appear. The
- tables do not lay out the restrictions of property parameters. Those
- restrictions are defined in [iCAL].
-
- Component/Property Presence
- ------------------- ----------------------------------------------
- CALSCALE 0 or 1
- PRODID 1
- VERSION 1 Value MUST be "2.0"
- X-PROPERTY 0+
-
-
- DateTime values MAY refer to a "VTIMEZONE" component. The property
- restrictions in the table below apply to any "VTIMEZONE" component in
- an ITIP message.
-
- Component/Property Presence
- ------------------- ----------------------------------------------
- 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 or 1
- DTSTART 1 MUST be local time format
- RDATE 0+ if present RRULE MUST NOT be present
- RRULE 0+ if present RDATE MUST NOT be present
- TZNAME 0 or 1
- TZOFFSET 1
- TZOFFSETFROM 1
- TZOFFSETTO 1
-
-
-
-Silverberg, et. al. Standards Track [Page 13]
-
-RFC 2446 iTIP November 1998
-
-
- X-PROPERTY 0+
- LAST-MODIFIED 0 or 1
- STANDARD 0+ MUST be one or more of either STANDARD or
- DAYLIGHT
- COMMENT 0 or 1
- DTSTART 1 MUST be local time format
- RDATE 0+ if present RRULE MUST NOT be present
- RRULE 0+ if present RDATE MUST NOT be present
- TZNAME 0 or 1
- TZOFFSETFROM 1
- TZOFFSETTO 1
- X-PROPERTY 0+
- TZID 1
- TZURL 0 or 1
- X-PROPERTY 0+
-
- The property restrictions in the table below apply to any "VALARM"
- component in an ITIP message.
-
- Component/Property Presence
- ------------------- ----------------------------------------------
- VALARM 0+
- ACTION 1
- ATTACH 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
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 14]
-
-RFC 2446 iTIP November 1998
-
-
- The following summarizes the methods that are defined for the
- "VEVENT" calendar component.
-
- +================+==================================================+
- | 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 an |
- | | 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.
-
-
-
-Silverberg, et. al. Standards Track [Page 15]
-
-RFC 2446 iTIP November 1998
-
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-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 or 1 This property may contain a list of
- values
- CLASS 0 or 1
- COMMENT 0 or 1
- 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
- EXDATE 0+
- EXRULE 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 or 1 This property MAY contain a list of values
- RRULE 0+
- STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED
- TRANSP 0 or 1
- URL 0 or 1
- X-PROPERTY 0+
-
- ATTENDEE 0
- REQUEST-STATUS 0
-
-VALARM 0+
-VFREEBUSY 0
-VJOURNAL 0
-
-
-
-Silverberg, et. al. Standards Track [Page 16]
-
-RFC 2446 iTIP November 1998
-
-
-VTODO 0
-VTIMEZONE 0+ MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-
-3.2.2 REQUEST
-
- The "REQUEST" method in a "VEVENT" component provides the following
- scheduling functions:
-
- . Invite "Attendees" to an event;
- . Reschedule an existing event;
- . Response to a REFRESH request;
- . Update the details of an existing event, without rescheduling it;
- . Update the status of "Attendees" of an existing event, without
- rescheduling it;
- . Reconfirm an existing event, without rescheduling it;
- . Forward a "VEVENT" to another uninvited CU.
- . For an existing "VEVENT" calendar component, delegate the role of
- "Attendee" to another CU;
- . For an existing "VEVENT" calendar component, changing 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".
-
- 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 reconfirm of the
- "VEVENT" calendar component.
-
- For the "REQUEST" method, multiple "VEVENT" components in a single
- iCalendar object are only permitted when 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.
-
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 17]
-
-RFC 2446 iTIP November 1998
-
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
------------------------------------------------------------------
-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 or 1 This property may contain a list of values
- CLASS 0 or 1
- COMMENT 0 or 1
- 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
- EXDATE 0+
- EXRULE 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 or 1 This property MAY contain a list of values
- RRULE 0+
- STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED
- TRANSP 0 or 1
- URL 0 or 1
- X-PROPERTY 0+
-
-VALARM 0+
-VTIMEZONE 0+ MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-
-
-
-Silverberg, et. al. Standards Track [Page 18]
-
-RFC 2446 iTIP November 1998
-
-
-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.
-
-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 no 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.
-
-
-
-Silverberg, et. al. Standards Track [Page 19]
-
-RFC 2446 iTIP November 1998
-
-
- 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".
-
- 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.
-
- 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 value of the "ORGANIZER" property has been changed to
- the calendar address of 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"
- was 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 an event may invite another uninvited CU to
- the event. The invited "Attendee" accomplishes this by forwarding the
- original "REQUEST" method to the uninvited CU. The "Organizer"
- decides whether or not the uninvited CU is added to the attendee
-
-
-
-Silverberg, et. al. Standards Track [Page 20]
-
-RFC 2446 iTIP November 1998
-
-
- list. If the "Organizer" decides not to add the uninvited CU no
- further action is required, however the "Organizer" MAY send the
- uninvited CU a "CANCEL" message. If the "Organizer" decides to add
- an uninvited CU, a new "ATTENDEE" property is added for the uninvited
- CU with its property parameters set as the "Organizer" deems
- appropriate. When forwarding a "REQUEST" to another CU, the
- forwarding "Attendee" MUST NOT make changes to the VEVENT property
- set.
-
-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 may also be used to respond to an unsuccessful
- "REQUEST" method. 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" can 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.
-
-
-
-
-Silverberg, et. al. Standards Track [Page 21]
-
-RFC 2446 iTIP November 1998
-
-
- 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:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-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 MUST if non-zero, MUST be the sequence
- number of the original REQUEST. MAY be
- present if 0.
-
- ATTACH 0+
- CATEGORIES 0 or 1 This property may contain a list of values
- CLASS 0 or 1
- COMMENT 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+
- EXRULE 0+
- GEO 0 or 1
- LAST-MODIFIED 0 or 1
- LOCATION 0 or 1
- PRIORITY 0 or 1
- RDATE 0+
- RELATED-TO 0+
-
-
-
-Silverberg, et. al. Standards Track [Page 22]
-
-RFC 2446 iTIP November 1998
-
-
- RESOURCES 0 or 1 This property MAY contain a list of values
- REQUEST-STATUS 0+
- RRULE 0+
- STATUS 0 or 1
- SUMMARY 0 or 1
- TRANSP 0 or 1
- URL 0 or 1
- X-PROPERTY 0+
-
-VTIMEZONE 0 or 1 MUST be present if any date/time refers
- to a timezone
-X-COMPONENT 0+
-
-VALARM 0
-VFREEBUSY 0
-VJOURNAL 0
-VTODO 0
-
-3.2.4 ADD
-
- The "ADD" method in a "VEVENT" calendar component is used to add one
- or more instances to an existing "VEVENT". Unlike the "REQUEST"
- method, when using issuing an "ADD" method, the "Organizer" does not
- send the full "VEVENT" description; only the new instance(s). The
- "ADD" method is especially useful if there are instance-specific
- properties to be preserved in a recurring "VEVENT". For instance, an
- "Organizer" may have originally scheduled a weekly Thursday meeting.
- At some point, several instances changed. Location or start time may
- have changed, or some instances may have unique "DESCRIPTION"
- properties. The "ADD" method allows the "Organizer" to add new
- instances to an existing event using a single ITIP message without
- redefining the entire recurring pattern.
-
- 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".
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 23]
-
-RFC 2446 iTIP November 1998
-
-
-Component/Property Presence
-------------------- ----------------------------------------------
-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 or 1 This property MAY contain a list of values
- CLASS 0 or 1
- COMMENT 0 or 1
- 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
- EXDATE 0+
- EXRULE 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 or 1 This property MAY contain a list of values
- RRULE 0+
- STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED
- TRANSP 0 or 1
- URL 0 or 1
- X-PROPERTY 0+
-
- RECURRENCE-ID 0
- REQUEST-STATUS 0
-
-VALARM 0+
-VTIMEZONE 0+ MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-
-VFREEBUSY 0
-VTODO 0
-VJOURNAL 0
-
-
-
-
-Silverberg, et. al. Standards Track [Page 24]
-
-RFC 2446 iTIP November 1998
-
-
-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
- "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 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
- THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the
- specified "VEVENT" calendar component and all instances before
- (or after); or
-
- (b) individual recurrence instances may be cancelled by specifying
- multiple "RECURRENCE-ID" properties corresponding to the
- instances to be cancelled.
-
- When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
- incremented.
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-METHOD 1 MUST be "CANCEL"
-
-VEVENT 1+ All must have the same UID
- ATTENDEE 0+ MUST include all "Attendees" being removed
- the event. MUST include 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 or 1
- ATTACH 0+
- CATEGORIES 0 or 1 This property may contain a list of values
-
-
-
-Silverberg, et. al. Standards Track [Page 25]
-
-RFC 2446 iTIP November 1998
-
-
- 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+
- EXRULE 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 MUST be present if referring to one or
- more or more recurring instances.
- Otherwise it MUST NOT be present
- RELATED-TO 0+
- RESOURCES 0 or 1
- RRULE 0+
- STATUS 0 or 1 MUST be set to CANCELLED. If uninviting
- specific "Attendees" then MUST NOT be
- included.
- SUMMARY 0 or 1
- TRANSP 0 or 1
- URL 0 or 1
- X-PROPERTY 0+
- REQUEST-STATUS 0
-
-VTIMEZONE 0+ MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-
-VTODO 0
-VJOURNAL 0
-VFREEBUSY 0
-VALARM 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.
-
-
-
-
-Silverberg, et. al. Standards Track [Page 26]
-
-RFC 2446 iTIP November 1998
-
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-METHOD 1 MUST be "REFRESH"
-
-VEVENT 1
- ATTENDEE 1 MUST be the address of requestor
- DTSTAMP 1
- ORGANIZER 1
- UID 1 MUST be the UID associated with original
- REQUEST
- COMMENT 0 or 1
- RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
- recurring calendar component. Otherwise
- it must NOT be present.
- X-PROPERTY 0+
-
- ATTACH 0
- CATEGORIES 0
- CLASS 0
- CONTACT 0
- CREATED 0
- DESCRIPTION 0
- DTEND 0
- DTSTART 0
- DURATION 0
- EXDATE 0
- EXRULE 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
-
-X-COMPONENT 0+
-
-VTODO 0
-
-
-
-Silverberg, et. al. Standards Track [Page 27]
-
-RFC 2446 iTIP November 1998
-
-
-VJOURNAL 0
-VFREEBUSY 0
-VTIMEZONE 0
-VALARM 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 description. The "Attendee" sends this
- message to the "Organizer" of the event.
-
- The counter proposal is an iCalendar object consisting of a VEVENT
- calendar component describing the complete description of the
- alternate event.
-
- The "Organizer" rejects the counter proposal by sending the
- "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts
- the counter proposal by rescheduling the event as described in
- section 3.2.2.1 Rescheduling an Event.
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-METHOD 1 MUST be "COUNTER"
-
-VEVENT 1
- DTSTAMP 1
- DTSTART 1
- ORGANIZER 1 MUST be the "Organizer" of the original
- event
- SEQUENCE 1 MUST be present if value is greater than 0,
- MAY be present if 0
- 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 or 1 This property may contain a list of values
- CLASS 0 or 1
- COMMENT 0 or 1
- CONTACT 0+
- CREATED 0 or 1
- DESCRIPTION 0 or 1
-
-
-
-Silverberg, et. al. Standards Track [Page 28]
-
-RFC 2446 iTIP November 1998
-
-
- DTEND 0 or 1 if present DURATION MUST NOT be present
- DURATION 0 or 1 if present DTEND MUST NOT be present
- EXDATE 0+
- EXRULE 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 MUST 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 or 1 This property may contain a list of values
- RRULE 0+
- STATUS 0 or 1 Value must be one of CONFIRMED/TENATIVE/
- CANCELLED
- TRANSP 0 or 1
- URL 0 or 1
- X-PROPERTY 0+
-
-VALARM 0+
-VTIMEZONE 0+ MUST be present if any date/time refers to
- a timezone
-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:
-
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 29]
-
-RFC 2446 iTIP November 1998
-
-
-Component/Property Presence
-------------------- ----------------------------------------------
-METHOD 1 MUST be "DECLINECOUNTER"
-
-VEVENT 1
- DTSTAMP 1
- ORGANIZER 1
- UID 1 MUST, same UID specified in original
- REQUEST and subsequent COUNTER
- COMMENT 0 or 1
- RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
- recurring calendar component. Otherwise it
- MUST NOT be present.
- REQUEST-STATUS 0+
- SEQUENCE 0 OR 1 MUST be present if value is greater than 0,
- MAY be present if 0
- X-PROPERTY 0+
- ATTACH 0
- ATTENDEE 0
- CATEGORIES 0
- CLASS 0
- CONTACT 0
- CREATED 0
- DESCRIPTION 0
- DTEND 0
- DTSTART 0
- DURATION 0
- EXDATE 0
- EXRULE 0
- GEO 0
- LAST-MODIFIED 0
- LOCATION 0
- PRIORITY 0
- RDATE 0
- RELATED-TO 0
- RESOURCES 0
- RRULE 0
- STATUS 0
- SUMMARY 0
- TRANSP 0
- URL 0
-
-X-COMPONENT 0+
-VTODO 0
-VJOURNAL 0
-VFREEBUSY 0
-VTIMEZONE 0
-VALARM 0
-
-
-
-Silverberg, et. al. Standards Track [Page 30]
-
-RFC 2446 iTIP November 1998
-
-
-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 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 "ATTENDEE",
- "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.
-
- 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.
-
- Since events may span a day boundary, free busy time period may also
- span a day boundary. Individual "A" requests busy time from
- individuals "B", "C" and "D". Individual "B" and "C" replies with
- busy time data to individual "A". Individual "D" does not support
- busy time requests and does not reply with any data. If the transport
- binding supports exception messages, then individual "D" returns an
- "unsupported capability" message to individual "A4.34.3".
-
- The following summarizes the methods that are defined for the
- "VFREEBUSY" calendar component.
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 31]
-
-RFC 2446 iTIP November 1998
-
-
- |================|==================================================|
- | 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 message for sending
- unsolicited busy time data. That is, the busy time data is not being
- sent as a "REPLY" to the receipt of a "REQUEST" method.
-
- The "ATTENDEE" property must be specified in the busy time
- information. The value is the CU address of the originator of the
- busy time information.
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-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 1+ MUST be BUSYTIME. Multiple instances are
- allowed. Multiple instances must be sorted
- in ascending order
- ORGANIZER 1 MUST contain the address of originator of
- busy time data.
-
- COMMENT 0 or 1
- CONTACT 0+
- X-PROPERTY 0+
- URL 0 or 1 Specifies busy time URL
-
- ATTENDEE 0
- DURATION 0
- REQUEST-STATUS 0
- UID 0
-
-X-COMPONENT 0+
-
-
-
-Silverberg, et. al. Standards Track [Page 32]
-
-RFC 2446 iTIP November 1998
-
-
-VEVENT 0
-VTODO 0
-VJOURNAL 0
-VTIMEZONE 0
-VALARM 0
-
-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 to 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:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-METHOD 1 MUST be "REQUEST"
-
-VFREEBUSY 1
- ATTENDEE 1+ contain the address of the calendar store
- 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 or 1
- CONTACT 0+
- X-PROPERTY 0+
-
- FREEBUSY 0
- DURATION 0
- REQUEST-STATUS 0
- URL 0
-
-X-COMPONENT 0+
-VALARM 0
-VEVENT 0
-
-
-
-Silverberg, et. al. Standards Track [Page 33]
-
-RFC 2446 iTIP November 1998
-
-
-VTODO 0
-VJOURNAL 0
-VTIMEZONE 0
-
-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:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-METHOD 1 MUST be "REPLY"
-
-VFREEBUSY 1
- ATTENDEE 1 (address of recipient replying)
- DTSTAMP 1
- DTEND 1 DateTime values must be in UTC
- DTSTART 1 DateTime values must be in UTC
- FREEBUSY 1+ (values MUST all be of the same data
- type. Multiple instances are allowed.
- Multiple instances MUST be sorted in
- ascending order. Values MAY NOT overlap)
- ORGANIZER 1 MUST be the request originator's address
- UID 1
-
- COMMENT 0 or 1
- CONTACT 0+
- REQUEST-STATUS 0+
- URL 0 or 1 (specifies busy time URL)
- X-PROPERTY 0+
- DURATION 0
- SEQUENCE 0
-
-X-COMPONENT 0+
-VALARM 0
-VEVENT 0
-VTODO 0
-VJOURNAL 0
-VTIMEZONE 0
-
-
-
-
-Silverberg, et. al. Standards Track [Page 34]
-
-RFC 2446 iTIP November 1998
-
-
-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 maybe 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
- "Organizer" MAY subsequently update (with another "PUBLISH" method),
- add instances to (with an "ADD" method), or cancel (with a "CANCEL"
-
-
-
-Silverberg, et. al. Standards Track [Page 35]
-
-RFC 2446 iTIP November 1998
-
-
- method) a previously published "VTODO" calendar component.
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-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 or 1 This property may contain a list of values
- CLASS 0 or 1
- COMMENT 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+
- EXRULE 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 MUST only if referring to an instance of a
- recurring calendar component. Otherwise
- it MUST NOT be present.
-
- RELATED-TO 0+
- RESOURCES 0 or 1 This property may contain a list of values
- RRULE 0+
-STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
- PROCESS/CANCELLED
- URL 0 or 1
- X-PROPERTY 0+
-
- ATTENDEE 0
- REQUEST-STATUS 0
-
-
-
-Silverberg, et. al. Standards Track [Page 36]
-
-RFC 2446 iTIP November 1998
-
-
-VTIMEZONE 0+ MUST be present if any date/time refers to
- a timezone
-VALARM 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:
-
- . Assign a to-do to one or more "Calendar Users";
- . Reschedule an existing to-do;
- . Update the details of an existing to-do, without rescheduling
- it;
- . Update the completion status of "Attendees" of an existing
- to-do, without rescheduling it;
- . Reconfirm an existing to-do, without rescheduling it;
- . 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.
-
- The originator of a "REQUEST" is the "Organizer" of the to-do. 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 reconfirm 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 when for components with the same
- "UID" property. That is, a series of recurring events may have
-
-
-
-Silverberg, et. al. Standards Track [Page 37]
-
-RFC 2446 iTIP November 1998
-
-
- 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:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-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.
- UID 1
-
- ATTACH 0+
- CATEGORIES 0 or 1 This property may contain a list of
- values
- CLASS 0 or 1
- COMMENT 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+
- EXRULE 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 present if referring to an instance of a
- recurring calendar component. Otherwise
- it MUST NOT be present.
- RELATED-TO 0+
- RESOURCES 0 or 1 This property may contain a list of
- values
- RRULE 0+
- STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
- PROCESS
- URL 0 or 1
- X-PROPERTY 0+
-
-
-
-Silverberg, et. al. Standards Track [Page 38]
-
-RFC 2446 iTIP November 1998
-
-
- REQUEST-STATUS 0
-
-VALARM 0+
-
-VTIMEZONE 0+ MUST be present if any date/time refers
- to a timezone
-X-COMPONENT 0+
-
-VEVENT 0
-VFREEBUSY 0
-VJOURNAL 0
-
-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
- or 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 or recurrence intervals, nor
- generally to 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
-
-
-
-Silverberg, et. al. Standards Track [Page 39]
-
-RFC 2446 iTIP November 1998
-
-
- 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. An "Attendee" of
- a "VTODO" calendar component MUST NOT delegate to the "Organizer" of
- the event.
-
- 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
-
-
-
-Silverberg, et. al. Standards Track [Page 40]
-
-RFC 2446 iTIP November 1998
-
-
- "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"
- considers appropriate.
-
-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
-
-
-
-Silverberg, et. al. Standards Track [Page 41]
-
-RFC 2446 iTIP November 1998
-
-
- received from an unknown "Calendar User", having 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:
-
-Component/Property Presence
-------------------- ---------------------------------------------
-METHOD 1 MUST be "REPLY"
-VTODO 1+ All component MUST have the same UID
- ATTENDEE 1+
- DTSTAMP 1
- ORGANIZER 1
- REQUEST-STATUS 1+
- UID 1 MUST must be the address of the replying
- attendee
-
- ATTACH 0+
- CATEGORIES 0 or 1 This property may contain a list of values
- CLASS 0 or 1
- COMMENT 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+
- EXRULE 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 or 1 This property may contain a list of values
- RRULE 0+
- RECURRENCE-ID 0 or 1 MUST 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.
- STATUS 0 or 1
-
-
-
-Silverberg, et. al. Standards Track [Page 42]
-
-RFC 2446 iTIP November 1998
-
-
- SUMMARY 0 or 1 Can be null
- URL 0 or 1
- X-PROPERTY 0+
-
-VTIMEZONE 0 or 1 MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-
-VALARM 0
-VEVENT 0
-VFREEBUSY 0
-
-3.4.4 ADD
-
- The "ADD" method in a "VTODO" calendar component is used to add one
- or more instances to an 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 5.3 and ask
- for a "REFRESH".
-
- The "SEQUENCE" property value is incremented as the sequence of to-
- dos has changed.
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-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 or 1 This property may contain a list of
- values
- CLASS 0 or 1
- COMMENT 0 or 1
- CONTACT 0+
-
-
-
-Silverberg, et. al. Standards Track [Page 43]
-
-RFC 2446 iTIP November 1998
-
-
- 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+
- EXRULE 0+
- GEO 0 or 1
- LAST-MODIFIED 0 or 1
- LOCATION 0 or 1
- PERCENT-COMPLETE 0 or 1
- RDATE 0+
- RELATED-TO 0+
- RESOURCES 0 or 1 This property may contain a list of
- values
- RRULE 0+
- STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
- PROCESS
- URL 0 or 1
- X-PROPERTY 0+
-
- RECURRENCE-ID 0
- REQUEST-STATUS 0
-
-VALARM 0+
-VTIMEZONE 0+ MUST be present if any date/time refers
- to a timezone
-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
- "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.
-
-
-
-Silverberg, et. al. Standards Track [Page 44]
-
-RFC 2446 iTIP November 1998
-
-
- 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
- THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the
- specified "VTODO" calendar component and all instances before (or
- after); or
-
- (b) individual recurrence instances may be cancelled by specifying
- multiple "RECURRENCE-ID" properties corresponding to the
- instances to be cancelled.
-
- When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
- incremented.
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ---------------------------------------------
-METHOD 1 MUST be "CANCEL"
-VTODO 1
- ATTENDEE 0+ include all "Attendees" being removed from
- the todo. MUST include all "Attendees" if
- the entire todo is cancelled.
- UID 1 MUST echo original UID
- DTSTAMP 1
- ORGANIZER 1
- SEQUENCE 1
-
- ATTACH 0+
- CATEGORIES 0 or 1 This property MAY contain a list of values
- CLASS 0 or 1
- COMMENT 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+
- EXRULE 0+
- GEO 0 or 1
- LAST-MODIFIED 0 or 1
- LOCATION 0 or 1
- PERCENT-COMPLETE 0 or 1
- RDATE 0+
-
-
-
-Silverberg, et. al. Standards Track [Page 45]
-
-RFC 2446 iTIP November 1998
-
-
- RECURRENCE-ID 0 or 1 MUST only if referring to one or more
- instances of a recurring calendar
- component. Otherwise it MUST NOT be
- present.
- RELATED-TO 0+
- RESOURCES 0 or 1 This property MAY contain a list of values
- RRULE 0+
- PRIORITY 0 or 1
- STATUS 0 or 1 If present it MUST be set to "CANCELLED".
- MUST NOT be used if purpose is to remove
- "ATTENDEES" rather than cancel the entire
- VTODO.
- URL 0 or 1
- X-PROPERTY 0+
-
- REQUEST-STATUS 0
-
-VTIMEZONE 0 or 1 MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-
-VALARM 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.
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 46]
-
-RFC 2446 iTIP November 1998
-
-
-Component/Property Presence
-------------------- ---------------------------------------------
-METHOD 1 MUST be "REFRESH"
-VTODO 1
- ATTENDEE 1
- DTSTAMP 1
- UID 1 MUST echo original UID
-
- RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
- Recurring calendar component. Otherwise it
- MUST NOT be present
- X-PROPERTY 0+
-
- ATTACH 0
- CATEGORIES 0
- CLASS 0
- COMMENT 0
- CONTACT 0
- CREATED 0
- DESCRIPTION 0
- DTSTART 0
- DUE 0
- DURATION 0
- EXDATE 0
- EXRULE 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
-
-X-COMPONENT 0+
-
-VALARM 0
-VEVENT 0
-VFREEBUSY 0
-VTIMEZONE 0
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 47]
-
-RFC 2446 iTIP November 1998
-
-
-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 "Attendee" sends the message to the "Organizer" of the "VTODO"
- calendar component.
-
- The counter proposal is an iCalendar object consisting of a "VTODO"
- calendar component describing 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 sending all of the "Attendees" of the "VTODO"
- calendar component a "REQUEST" method rescheduling the "VTODO"
- calendar component. In the latter case, the "Organizer" SHOULD reset
- the individual "RSVP" property parameter values to TRUE on each
- "ATTENDEE" property; in order to force a response by the "Attendees".
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-METHOD 1 MUST be "COUNTER"
-VTODO 1
- ATTENDEE 1+
- DTSTAMP 1
- ORGANIZER 1
- PRIORITY 1
- SUMMARY 1 Can be null
- UID 1
-
- ATTACH 0+
- CATEGORIES 0 or 1 This property MAY contain a list of values
- CLASS 0 or 1
- COMMENT 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+
- EXRULE 0+
- GEO 0 or 1
- LAST-MODIFIED 0 or 1
-
-
-
-Silverberg, et. al. Standards Track [Page 48]
-
-RFC 2446 iTIP November 1998
-
-
- LOCATION 0 or 1
- PERCENT-COMPLETE 0 or 1
- RDATE 0+
- RECURRENCE-ID 0 or 1 MUST only 3.5if referring to an instance of a
- recurring calendar component. Otherwise it
- MUST NOT be present.
- RELATED-TO 0+
- REQUEST-STATUS 0+
- RESOURCES 0 or 1 This property MAY contain a list of values
- 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
- X-PROPERTY 0+
-
-
-VALARM 0+
-VTIMEZONE 0 or 1 MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-
-VEVENT 0
-VFREEBUSY 0
-
-3.4.8 DECLINECOUNTER
-
- The "DECLINECOUNTER" method in a "VTODO" calendar component is used
- by an "Organizer" of "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:
-
-Component/Property Presence
-------------------- ---------------------------------------------
-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
-
-
-
-Silverberg, et. al. Standards Track [Page 49]
-
-RFC 2446 iTIP November 1998
-
-
- ATTACH 0+
- CATEGORIES 0 or 1 This property may contain a list of values
- CLASS 0 or 1
- COMMENT 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+
- EXRULE 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+
- RECURRENCE-ID 0 or 1 MUST 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 or 1 This property MAY contain a list of values
- RRULE 0+
- STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
- PROCESS
- URL 0 or 1
- X-PROPERTY 0+
-
-VTIMEZONE 0+ MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-
-VALARM 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.
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 50]
-
-RFC 2446 iTIP November 1998
-
-
- +================+==================================================+
- | 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:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-METHOD 1 MUST be "PUBLISH"
-VJOURNAL 1+
- DESCRIPTION 1 Can be null.
- DTSTAMP 1
- DTSTART 1
- ORGANIZER 1
- UID 1
-
- ATTACH 0+
- CATEGORIES 0 or 1 This property MAY contain a list of values
- CLASS 0 or 1
- COMMENT 0 or 1
- CONTACT 0+
- CREATED 0 or 1
- EXDATE 0+
- EXRULE 0+
- LAST-MODIFIED 0 or 1
- RDATE 0+
- RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
-
-
-
-Silverberg, et. al. Standards Track [Page 51]
-
-RFC 2446 iTIP November 1998
-
-
- recurring calendar component. Otherwise
- it MUST NOT be present.
- RELATED-TO 0+
- RRULE 0+
- 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 DRAFT/FINAL/CANCELLED
- SUMMARY 0 or 1 Can be null
- URL 0 or 1
- X-PROPERTY 0+
-
- ATTENDEE 0
-
-VALARM 0+
-VTIMEZONE 0+ MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-
-VEVENT 0
-VFREEBUSY 0
-VTODO 0
-
-3.5.2 ADD
-
- The "ADD" method in a "VJOURNAL" calendar component is used to add
- one or more instances to an existing "VJOURNAL" entry. There is no
- response to the "Organizer".
-
- 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".
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ----------------------------------------------
-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+
-
-
-
-Silverberg, et. al. Standards Track [Page 52]
-
-RFC 2446 iTIP November 1998
-
-
- CATEGORIES 0 or 1 This property MAY contain a list of values
- CLASS 0 or 1
- COMMENT 0 or 1
- CONTACT 0+
- CREATED 0 or 1
- EXDATE 0+
- EXRULE 0+
- LAST-MODIFIED 0 or 1
- RDATE 0+
- RELATED-TO 0+
- RRULE 0+
- STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED
- SUMMARY 0 or 1 Can be null
- URL 0 or 1
- X-PROPERTY 0+
-
- ATTENDEE 0
- RECURRENCE-ID 0
-
-VALARM 0+
-VTIMEZONE 0 or 1 MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-
-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:
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 53]
-
-RFC 2446 iTIP November 1998
-
-
- (a) the "RECURRENCE-ID" property for an instance in the sequence MUST
- be specified with the "RANGE" property parameter value of
- THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the
- specified "VTODO" calendar component and all instances before (or
- after); or
-
- (b) individual recurrence instances may be cancelled by specifying
- multiple "RECURRENCE-ID" properties corresponding to the
- instances to be cancelled.
-
- When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be
- incremented.
-
- This method type is an iCalendar object that conforms to the
- following property constraints:
-
-Component/Property Presence
-------------------- ---------------------------------------------
-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 or 1 This property MAY contain a list of values
- CLASS 0 or 1
- COMMENT 0 or 1
- CONTACT 0+
- CREATED 0 or 1
- DESCRIPTION 0 or 1
- DTSTART 0 or 1
- EXDATE 0+
- EXRULE 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+
- STATUS 0 or 1 MAY be present, must be "CANCELLED" if
- present
- SUMMARY 0 or 1
- URL 0 or 1
- X-PROPERTY 0+
-
-
-
-Silverberg, et. al. Standards Track [Page 54]
-
-RFC 2446 iTIP November 1998
-
-
- REQUEST-STATUS 0
-
-VTIMEZONE 0+ MUST be present if any date/time refers to
- a timezone
-X-COMPONENT 0+
-VALARM 0
-VEVENT 0
-VFREEBUSY 0
-VTODO 0
-
-3.6 Status Replies
-
- The "REQUEST-STATUS" property may include the following values:
-
-|==============+============================+=========================|
-| Short Return | Longer Return Status | Offending Data |
-| Status Code | Description | |
-|==============+============================+=========================|
-| 2.0 | Success. | None. |
-|==============+============================+=========================|
-| 2.1 | Success but fallback taken | Property name and value |
-| | on one or more property | MAY be specified. |
-| | values. | |
-|==============+============================+=========================|
-| 2.2 | Success, invalid property | Property name MAY be |
-| | ignored. | specified. |
-|==============+============================+=========================|
-| 2.3 | Success, invalid property | Property parameter name |
-| | parameter ignored. | and value MAY be |
-| | | specified. |
-|==============+============================+=========================|
-| 2.4 | Success, unknown non- | Non-standard property |
-| | standard property ignored. | name MAY be specified. |
-|==============+============================+=========================|
-| 2.5 | Success, unknown non | Property and non- |
-| | standard property value | standard value MAY be |
-| | ignored. | specified. |
-|==============+============================+=========================|
-| 2.6 | Success, invalid calendar | Calendar component |
-| | component ignored. | sentinel (e.g., BEGIN: |
-| | | ALARM) MAY be |
-| | | specified. |
-|==============+============================+=========================|
-| 2.7 | Success, request forwarded | Original and forwarded |
-| | to Calendar User. | caluser addresses MAY |
-| | | be specified. |
-|==============+============================+=========================|
-| 2.8 | Success, repeating event | RRULE or RDATE property |
-
-
-
-Silverberg, et. al. Standards Track [Page 55]
-
-RFC 2446 iTIP November 1998
-
-
-| | ignored. Scheduled as a | name and value MAY be |
-| | single component. | specified. |
-|==============+============================+=========================|
-| 2.9 | Success, truncated end date| DTEND property value |
-| | time to date boundary. | MAY be specified. |
-|==============+============================+=========================|
-| 2.10 | Success, repeating VTODO | RRULE or RDATE property |
-| | ignored. Scheduled as a | name and value MAY be |
-| | single VTODO. | specified. |
-|==============+============================+=========================|
-| 2.11 | Success, unbounded RRULE | RRULE property name and |
-| | clipped at some finite | value MAY be specified. |
-| | number of instances | Number of instances MAY |
-| | | also be specified. |
-|==============+============================+=========================|
-| 3.0 | Invalid property name. | Property name MAY be |
-| | | specified. |
-|==============+============================+=========================|
-| 3.1 | Invalid property value. | Property name and value |
-| | | MAY be specified. |
-|==============+============================+=========================|
-| 3.2 | Invalid property parameter.| Property parameter name |
-| | | and value MAY be |
-| | | specified. |
-|==============+============================+=========================|
-| 3.3 | Invalid property parameter | Property parameter name |
-| | value. | and value MAY be |
-| | | specified. |
-|==============+============================+=========================|
-| 3.4 | Invalid calendar component | Calendar component |
-| | sequence. | sentinel MAY be |
-| | | specified (e.g., BEGIN: |
-| | | VTIMEZONE). |
-|==============+============================+=========================|
-| 3.5 | Invalid date or time. | Date/time value(s) MAY |
-| | | be specified. |
-|==============+============================+=========================|
-| 3.6 | Invalid rule. | Rule value MAY be |
-| | | specified. |
-|==============+============================+=========================|
-| 3.7 | Invalid Calendar User. | Attendee property value |
-| | |MAY be specified. |
-|==============+============================+=========================|
-| 3.8 | No authority. | METHOD and Attendee |
-| | | property values MAY be |
-| | | specified. |
-|==============+============================+=========================|
-
-
-
-
-Silverberg, et. al. Standards Track [Page 56]
-
-RFC 2446 iTIP November 1998
-
-
-| 3.9 | Unsupported version. | VERSION property name |
-| | | and value MAY be |
-| | | specified. |
-|==============+============================+=========================|
-| 3.10 | Request entity too large. | None. |
-|==============+============================+=========================|
-| 3.11 | Required component or | Component or property |
-| | property missing. | name MAY be specified. |
-|==============+============================+=========================|
-| 3.12 | Unknown component or | Component or property |
-| | property found | name MAY be specified |
-|==============+============================+=========================|
-| 3.13 | Unsupported component or | Component or property |
-| | property found | name MAY be specified |
-|==============+============================+=========================|
-| 3.14 | Unsupported capability | Method or action MAY |
-| | | be specified |
-|==============+============================+=========================|
-| 4.0 | Event conflict. Date/time | DTSTART and DTEND |
-| | is busy. | property name and values|
-| | | MAY be specified. |
-|==============+============================+=========================|
-| 5.0 | Request MAY supported. | Method property value |
-| | | MAY be specified. |
-|==============+============================+=========================|
-| 5.1 | Service unavailable. | ATTENDEE property value |
-| | | MAY be specified. |
-|==============+============================+=========================|
-| 5.2 | Invalid calendar service. | ATTENDEE property value |
-| | | MAY be specified. |
-|==============+============================+=========================|
-| 5.3 | No scheduling support for | ATTENDEE property value |
-| | user. | MAY be specified. |
-|==============+============================+=========================|
-
-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.
-
-
-
-
-Silverberg, et. al. Standards Track [Page 57]
-
-RFC 2446 iTIP November 1998
-
-
- Since implementations may elect to store recurring events as either a
- single event object or a collection of discreet, 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 component components) and possibly description.
-
- "Organizer" initiated actions:
-
- . "Organizer" deletes or changes a single instance of a recurring
- event
- . "Organizer" makes changes that affect all future instances
- . "Organizer" makes changes that affect all previous instances
- . "Organizer" deletes or modifies a previously changed instance
-
- "Attendee" initiated actions:
-
- . "Attendee" changes status for a particular recurrence instance
- . "Attendee" sends Event-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 be 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 "DTSTART" value is used for
- "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
- reflect the change. Note that after the change has occurred, the
- "RECURRENCE-ID" has changed to the new "DTSTART" value.
-
-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
-
-
-
-Silverberg, et. al. Standards Track [Page 58]
-
-RFC 2446 iTIP November 1998
-
-
- authorizing an update. Second, it is prudent to provide a point of
- contact for anyone who receives a published component in case of
- problems.
-
- There are valid [RFC-822] addresses that represent groups. Sending
- email to such an address results in mail 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
- "TYPE=INDIVIDUAL"
-
- 2. Failing (1) look for attendees where "TYPE=GROUP" or
- 'TYPE=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
- . 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 X-Tokens
-
- To make iCalendar objects extensible, new property types MAY be
- inserted into components. These properties are called X-Tokens as
- they are prefixed with "X-". A client is not required to make sense
- of X-Tokens. Clients are not required to save X-Tokens or use them
- in replies.
-
-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, e-
- mailing the event to a distribution list, and posting the event to a
- newsgroup.
-
-
-
-Silverberg, et. al. Standards Track [Page 59]
-
-RFC 2446 iTIP November 1998
-
-
- The table below illustrates the sequence of events between the
- publisher and the consumers of a published event.
-
- +-------------------------------------------------------------------+
- | Action | "Organizer" |
- +---------------------------------+---------------------------------+
- | Publish an event | "A" sends or posts a PUBLISH |
- | | message |
- +---------------------------------+---------------------------------+
- | "B" reads a published event | |
- +---------------------------------+---------------------------------+
- | Publish an updated event | "A" sends or posts a PUBLISH |
- | | message |
- +---------------------------------+---------------------------------+
- | "B" reads the updated event | |
- +---------------------------------+---------------------------------+
- | Cancel a published event | "A" sends or posts a CANCEL |
- | | message |
- +---------------------------------+---------------------------------+
- | "B" reads the canceled event | |
- | publication | |
- +---------------------------------+---------------------------------+
-
-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:-//ACME/DesktopCalendar//EN
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:mailto:a at example.com
- DTSTART:19970701T200000Z
- DTSTAMP:19970611T190000Z
- SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
- UID:0981234-1234234-23 at 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 4.1.1, the time has been changed, an end time has been added, and
- the sequence number has been adjusted.
-
-
-
-
-Silverberg, et. al. Standards Track [Page 60]
-
-RFC 2446 iTIP November 1998
-
-
- BEGIN:VCALENDAR
- METHOD:PUBLISH
- VERSION:2.0
- PRODID:-//ACME/DesktopCalendar//EN
- BEGIN:VEVENT
- ORGANIZER:mailto:a at example.com
- DTSTAMP:19970612T190000Z
- DTSTART:19970701T210000Z
- DTEND:19970701T230000Z
- SEQUENCE:1
- UID:0981234-1234234-23 at 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
- 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 4.1.1. This
- cancels the event with "SEQUENCE" property of 0, 1, and 2.
-
- BEGIN:VCALENDAR
- METHOD:CANCEL
- VERSION:2.0
- PRODID:-//ACME/DesktopCalendar//EN
- BEGIN:VEVENT
- ORGANIZER:mailto:a at example.com
- COMMENT:DUKES forfeit the game
- SEQUENCE:2
- UID:0981234-1234234-23 at example.com
- DTSTAMP:19970613T190000Z
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 61]
-
-RFC 2446 iTIP November 1998
-
-
-4.1.4 A Rich Published Event
-
- This example describes the same event as in 4.1.1, but in much
- greater detail.
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:PUBLISH
- SCALE:GREGORIAN
- VERSION:2.0
- BEGIN:VTIMEZONE
- TZID:America-Chicago
- TZURL:http://zones.stds_r_us.net/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
- TZOFFSETFROM:-0600
- TZOFFSETTO:-0500
- TZNAME:CDT
- END:DAYLIGHT
- END:VTIMEZONE
- BEGIN:VEVENT
- ORGANIZER:mailto:a at example.com
- ATTACH:http://www.dukes.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://www.midwaystadium.com/
- PRIORITY:2
- RESOURCES:SCOREBOARD
- SEQUENCE:3
- SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
- UID:0981234-1234234-23 at example.com
- RELATED-TO:0981234-1234234-14 at example.com
- BEGIN:VALARM
-
-
-
-Silverberg, et. al. Standards Track [Page 62]
-
-RFC 2446 iTIP November 1998
-
-
- 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.
-
-4.1.5 Anniversaries or Events attached to entire days
-
- This example demonstrates the use of the "value" parameter to tie a
- "VEVENT" to day rather than a specific time.
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:PUBLISH
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:mailto:a at example.com
- DTSTAMP:19970614T190000Z
- UID:0981234-1234234-23 at 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 that 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 the message flow between these
- individuals. A, the CU scheduling the meeting, is referenced as the
- "Organizer".
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 63]
-
-RFC 2446 iTIP November 1998
-
-
-+---------------------------------------------------------------------+
-| Action | "Organizer" | Attendee |
-+---------------------------------------------------------------------+
-| Initiate a meeting | "A" sends a REQUEST | |
-| request | message to "B", "C",| |
-| | and "D" | |
-+---------------------------------------------------------------------+
-| Accept the meeting | | "B" sends a REPLY |
-| request | | message to "A" with its |
-| | | ATTENDEE "partstat" para-|
-| | | set to "accepted" |
-+---------------------------------------------------------------------+
-| Decline the meeting| | "C" sends a REPLY |
-| request | | message to "A" with its |
-| | | ATTENDEE "partstat" para-|
-| | | set to "declined" |
-+---------------------------------------------------------------------+
-| Tentatively accept | | "D" sends a REPLY |
-| the meeting request| | message to "A" with its |
-| | | ATTENDEE "partstat" para-|
-| | | set to "tentative" |
-+---------------------------------------------------------------------+
-| Confirm meeting | "A" sends a REQUEST | |
-| status with | message to "B" and | |
-| attendees | "D" with updated | |
-| | 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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C at example.com
-
-
-
-Silverberg, et. al. Standards Track [Page 64]
-
-RFC 2446 iTIP November 1998
-
-
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D at example.com
- ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big at example.com
- ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E at example.com
- DTSTAMP:19970611T190000Z
- DTSTART:19970701T200000Z
- DTEND:19970701T2000000Z
- SUMMARY:Conference
- UID:calsrv.example.com-873970198738777 at 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:-//ACME/DesktopCalendar//EN
- METHOD:REPLY
- VERSION:2.0
- BEGIN:VEVENT
- ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B at example.com
- ORGANIZER:MAILTO:A at example.com
- UID:calsrv.example.com-873970198738777 at 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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
-
-
-
-Silverberg, et. al. Standards Track [Page 65]
-
-RFC 2446 iTIP November 1998
-
-
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D at example.com
- ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
- CUTYPE=ROOM:Mailto:Conf at example.com
- ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E at example.com
- DTSTART:19970701T180000Z
- DTEND:19970701T190000Z
- SUMMARY:Phone Conference
- UID:calsrv.example.com-873970198738777 at 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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C at example.com
- DTSTART:19970701T190000Z
- DTEND:19970701T200000Z
- SUMMARY:Discuss the Merits of the election results
- LOCATION:Green Conference Room
- UID:calsrv.example.com-873970198738777a at example.com
- SEQUENCE:0
- DTSTAMP:19970611T190000Z
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
- "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".
-
-
-
-Silverberg, et. al. Standards Track [Page 66]
-
-RFC 2446 iTIP November 1998
-
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:COUNTER
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C at example.com
- DTSTART:19970701T160000Z
- DTEND:19970701T190000Z
- DTSTAMP:19970612T190000Z
- SUMMARY:Discuss the Merits of the election results
- LOCATION:Green Conference Room
- COMMENT:This time works much better and I think the big conference
- room is too big
- UID:calsrv.example.com-873970198738777a at example.com
- SEQUENCE:0
- DTSTAMP:19970611T190000Z
- 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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C at example.com
- DTSTAMP:19970613T190000Z
- DTSTART:19970701T160000Z
- DTEND:19970701T190000Z
- SUMMARY:Discuss the Merits of the election results - changed to
- meet B's schedule
- LOCATION:Green Conference Room
- UID:calsrv.example.com-873970198738777 at example.com
- SEQUENCE:1
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
- Instead, "A" rejects "B's" counter proposal
-
-
-
-Silverberg, et. al. Standards Track [Page 67]
-
-RFC 2446 iTIP November 1998
-
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:DECLINECOUNTER
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B at example.com
- COMMENT:Sorry, I cannot change this meeting time
- UID:calsrv.example.com-873970198738777 at 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:
-
- . Send a "REPLY" to the "Organizer" with the following updates:
- . The "Delegator's" "ATTENDEE" property "partstat" parameter set
- to "delegated" and the "delegated-to" parameter is set to the
- address of the "Delegate"
- . Add an additional "ATTENDEE" property for the "Delegate" with
- the "delegated-from" property parameter set to the "Delegator"
- . 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.
- . The "Delegator" MUST also send a copy of the original "REQUEST"
- method to the "Delegate".
-
- It is not required that the "Delegate" include the "Delegator" in
- their "REPLY" method. However, it is strongly advised since this will
- inform the "Delegator" whether the "Delegate" plans to attend the
- meeting. [Editors note: How so?] If the "Delegate" declines the
- meeting, the "Delegator" may elect to delegate the "REQUEST" to
- another CUA. The process is the same.
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 68]
-
-RFC 2446 iTIP November 1998
-
-
-+---------------------------------------------------------------------+
-| Action | "Organizer" | Attendee |
-+---------------------------------------------------------------------+
-| Initiate a meeting | "A" sends a REQUEST | |
-| request | message to "B" and | |
-| | "C" | |
-+---------------------------------------------------------------------+
-| Delegate: | | "C" sends a REPLY to "A" |
-| "C" delegates to | | with the ATTENDEE. |
-| "E" | | "partstat" parameter set |
-| | | to "delegated" and with a|
-| | | new "ATTENDEE" property |
-| | | for "E". "E's" ATTENDEE |
-| | | "delegated-from" param |
-| | | is set to "C". "C's" |
-| | | ATTENDEE "delegated-to" |
-| | | param 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 meeting | | "E" sends REPLY message |
-| attendance | | to "A" and optionally "C"|
-| | | with its "partstat" |
-| | | property parameter set |
-| | | to "ACCEPTED" |
-+---------------------------------------------------------------------+
-| Optional: | "A" sends REQUEST | |
-| Redistribute | message to "B", "C" | |
-| meeting to | and "E". | |
-| attendees | | |
-+---------------------------------------------------------------------+
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 69]
-
-RFC 2446 iTIP November 1998
-
-
- "C" responds to the "Organizer".
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:REPLY
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:MAILTO:A at Example.com
- ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
- TO="Mailto:E at example.com":Mailto:C at example.com
- UID:calsrv.example.com-873970198738777 at 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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
- TO="Mailto:E at example.com":Mailto:C at example.com
- ATTENDEE;RSVP=TRUE;
- DELEGATED-FROM="Mailto:C at example.com":Mailto:E at example.com
- DTSTART:19970701T180000Z
- DTEND:19970701T200000Z
- SUMMARY:Phone Conference
- UID:calsrv.example.com-873970198738777 at 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:-//ACME/DesktopCalendar//EN
- METHOD:REPLY
- VERSION:2.0
-
-
-
-Silverberg, et. al. Standards Track [Page 70]
-
-RFC 2446 iTIP November 1998
-
-
- BEGIN:VEVENT
- ORGANIZER:MAILTO:A at Example.com
- ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
- FROM="Mailto:C at example.com":Mailto:E at example.com
- ATTENDEE;PARTSTAT=DELEGATED;
- DELEGATED-TO="Mailto:E at example.com":Mailto:C at example.com
- UID:calsrv.example.com-873970198738777 at 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.
-
- Response from "E" to "A" and "C". Note the use of the "COMMENT"
- property "E" uses to indicate why the delegation was declined.
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:REPLY
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:MAILTO:A at Example.com
- ATTENDEE;PARTSTAT=DELEGATED;
- DELEGATED-TO="Mailto:E at example.com":Mailto:C at example.com
- ATTENDEE;PARTSTAT=DECLINED;
- DELEGATED-FROM="Mailto:C at example.com":Mailto:E at example.com
- COMMENT:Sorry, I will be out of town at that time.
- UID:calsrv.example.com-873970198738777 at 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.
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 71]
-
-RFC 2446 iTIP November 1998
-
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:MAILTO:A at Example.com
- ATTENDEE;PARTSTAT=DECLINED;
- DELEGATED-FROM="Mailto:C at example.com":Mailto:E at example.com
- ATTENDEE;RSVP=TRUE:Mailto:C at example.com
- UID:calsrv.example.com-873970198738777 at example.com
- SEQUENCE:0
- SUMMARY:Phone Conference
- DTSTART:19970701T180000Z
- DTEND:19970701T200000Z
- DTSTAMP:19970614T200000Z
- COMMENT:DELEGATE (ATTENDEE Mailto:E at 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" an
- "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.
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 72]
-
-RFC 2446 iTIP November 1998
-
-
- +--------------------------------------------------------------------+
- | Action | "Organizer" | "Attendee" |
- +--------------------------------------------------------------------+
- | Initiate a meeting | "A" sends a REQUEST | |
- | request | message to "B", "C",| |
- | | and "D" | |
- +--------------------------------------------------------------------+
- | Decline the meeting| | "B" sends a "REPLY" |
- | request | | message to "A" with its |
- | | | "partstat" para- |
- | | | set to "declined". |
- +--------------------------------------------------------------------+
- | Cancel the meeting | "A" sends a CANCEL | |
- | | message to "B", "C" | |
- | | and "D" | |
- +--------------------------------------------------------------------+
-
- The example shows how "A" cancels the event.
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:CANCEL
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;TYPE=INDIVIDUAL;Mailto:A at example.com
- ATTENDEE;TYPE=INDIVIDUAL:Mailto:B at example.com
- ATTENDEE;TYPE=INDIVIDUAL:Mailto:C at example.com
- ATTENDEE;TYPE=INDIVIDUAL:Mailto:D at example.com
- COMMENT:Mr. B cannot attend. It's raining. Lets cancel.
- UID:calsrv.example.com-873970198738777 at example.com
- SEQUENCE:1
- STATUS:CANCELLED
- DTSTAMP:19970613T190000Z
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 73]
-
-RFC 2446 iTIP November 1998
-
-
-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.
-
- +--------------------------------------------------------------------+
- | Action | "Organizer" | "Attendee" |
- +--------------------------------------------------------------------+
- | Remove an "B" | "A" sends a CANCEL | |
- | as an "Attendee" | message to "B" | |
- +--------------------------------------------------------------------+
- | Update the master | "A" sends the | |
- | copy of the event | updated 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:-//ACME/DesktopCalendar//EN
- METHOD:CANCEL
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE:mailto:B at example.com
- COMMENT:You're off the hook for this meeting
- UID:calsrv.example.com-873970198738777 at 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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
-
-
-
-Silverberg, et. al. Standards Track [Page 74]
-
-RFC 2446 iTIP November 1998
-
-
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;TYPE=INDIVIDUAL:Mailto:C at example.com
- ATTENDEE;TYPE=INDIVIDUAL:Mailto:D at example.com
- ATTENDEE;TYPE=ROOM:CR_Big at example.com
- ATTENDEE;ROLE=NON-PARTICIPANT;
- RSVP=FALSE:Mailto:E at example.com
- DTSTAMP:19970611T190000Z
- DTSTART:19970701T200000Z
- DTEND:19970701T203000Z
- SUMMARY:Phone Conference
- UID:calsrv.example.com-873970198738777 at 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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:B at example.com
- ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B at example.com
- ATTENDEE;TYPE=INDIVIDUAL:Mailto:C at example.com
- ATTENDEE;TYPE=INDIVIDUAL:Mailto:D at example.com
- DTSTAMP:19970611T190000Z
- DTSTART:19970701T200000Z
- DTEND:19970701T203000Z
- RRULE:FREQ=WEEKLY
- SUMMARY:Phone Conference
- UID:123456 at example.com
-
-
-
-Silverberg, et. al. Standards Track [Page 75]
-
-RFC 2446 iTIP November 1998
-
-
- SEQUENCE:1
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
-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.
-
- Individual "A" publishes busy time for one week.
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- VERSION:2.0
- METHOD:PUBLISH
- BEGIN:VFREEBUSY
- DTSTAMP:19980101T124100Z
- ORGANIZER:MAILTO:A at Example.com
- DTSTART:19980101T124200Z
- DTEND:19980107T124200Z
- 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
-
- Individual "A" requests busy time from individuals "B", "C".
- Individual "B" and "C" replies with busy time data to individual "A".
- The following table illustrates the sequence of messages that would
- be exchanged between these individuals.
-
-
-
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 76]
-
-RFC 2446 iTIP November 1998
-
-
-+--------------------------------------------------------------------+
-| Action | "Organizer" | Attendee |
-+--------------------------------------------------------------------+
-| Initiate a busy | "A" sends "REQUEST" | |
-| time request | message to "B" and | |
-| | and "C" | |
-+--------------------------------------------------------------------+
-| Reply to the "BUSY"| | "B" sends a "REPLY" |
-| request with "BUSY"| | message to "A" with |
-| time data | | busy time data |
-+--------------------------------------------------------------------+
-
-4.3.1 Request Busy Time
-
- "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VFREEBUSY
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR:Mailto:A at example.com
- ATTENDEE:Mailto:B at example.com
- ATTENDEE:Mailto:C at example.com
- DTSTAMP:19970613T190000Z
- DTSTART:19970701T080000Z
- DTEND:19970701T200000
- UID:calsrv.example.com-873970198738777 at example.com
- END:VFREEBUSY
- END:VCALENDAR
-
-4.3.2 Reply To A Busy Time Request
-
- "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component
- to "A"
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:REPLY
- VERSION:2.0
- BEGIN:VFREEBUSY
- ORGANIZER:MAILTO:A at example.com
- ATTENDEE:Mailto:B at example.com
- DTSTART:19970701T080000Z
- DTEND:19970701T200000Z
- UID:calsrv.example.com-873970198738777 at example.com
- FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M
-
-
-
-Silverberg, et. al. Standards Track [Page 77]
-
-RFC 2446 iTIP November 1998
-
-
- DTSTAMP:19970613T190030Z
- END:VFREEBUSY
- 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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VTIMEZONE
- TZID:America-SanJose
- TZURL:http://zones.stds_r_us.net/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 at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A at example.COM
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B at example.fr
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c at example.jp
- DTSTAMP:19970613T190030Z
- DTSTART;TZID=America-SanJose:19970701T140000
- DTEND;TZID=America-SanJose:19970701T150000
- RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU
- RDATE;TZID=America-SanJose:19970910T140000
- EXDATE;TZID=America-SanJose:19970909T140000
- EXDATE;TZID=America-SanJose:19971028T140000
- SUMMARY:Weekly Phone Conference
-
-
-
-Silverberg, et. al. Standards Track [Page 78]
-
-RFC 2446 iTIP November 1998
-
-
- UID:calsrv.example.com-873970198738777 at example.com
- SEQUENCE:0
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
- The first two components of this iCalendar object are the time zone
- components. 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.
- "Attendee" B at example.fr is in France where the local time on this
- date is 9 hours ahead of PDT or 23:00. "Attendee" C at example.jp is in
- Japan where local time is 8 hours ahead of UTC or Wednesday, July 2
- at 06:00. 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 PDT. The "RDATE" property adds
- another instance: WED, 10-SEP-1997 2:00 PM PST.
-
- There are two exceptions to this recurring appointment. The first one
- is:
-
- TUE, 09-SEP-1997 23:00 GMT
- TUE, 09-SEP-1997 14:00 PDT
- WED, 10-SEP-1997 06:00 JST
-
- and the second is:
-
- TUE, 28-OCT-1997 23:00 GMT
- TUE, 28-OCT-1997 14:00 PST
- WED, 29-OCT-1997 06:00 JST
-
-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.
-
- Original Request:
-
- BEGIN:VCALENDAR
- METHOD:REQUEST
-
-
-
-Silverberg, et. al. Standards Track [Page 79]
-
-RFC 2446 iTIP November 1998
-
-
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:guid-1 at host1.com
- SEQUENCE:0
- RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE:Mailto:B at example.com
- ATTENDEE:Mailto:C at example.com
- ATTENDEE:Mailto:D at 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:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:guid-1 at host1com
- RECURRENCE-ID:19970701T210000Z
- SEQUENCE:1
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE:Mailto:B at example.com
- ATTENDEE:Mailto:C at example.com
- ATTENDEE:Mailto:D at example.com
- DESCRIPTION:IETF-C&S Conference Call
- CLASS:PUBLIC
- SUMMARY:IETF Calendaring Working Group Meeting
- DTSTART:19970703T210000Z
- DTEND:19970703T220000Z
- LOCATION:Conference Call
- DTSTAMP:19970626T093000Z
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
-
-
-Silverberg, et. al. Standards Track [Page 80]
-
-RFC 2446 iTIP November 1998
-
-
-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:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:guid-1 at host1.com
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE:Mailto:B at example.com
- ATTENDEE:Mailto:C at example.com
- ATTENDEE:Mailto:D at example.com
- RECURRENCE-ID:19970801T210000Z
- SEQUENCE:2
- STATUS:CANCELLED
- DTSTAMP:19970721T093000Z
- END:VEVENT
- END:VCALENDAR
-
-4.4.4 Cancel Recurring Event
-
- In this example the "Organizer" wishes to cancel the entire recurring
- event and any exceptions.
-
- BEGIN:VCALENDAR
- METHOD:CANCEL
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:guid-1 at host1.com
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE:Mailto:B at example.com
- ATTENDEE:Mailto:C at example.com
- ATTENDEE:Mailto:D at example.com
- DTSTAMP:19970721T103000Z
- STATUS:CANCELLED
- SEQUENCE:3
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 81]
-
-RFC 2446 iTIP November 1998
-
-
-4.4.5 Change All Future Instances
-
- This example changes the meeting location from a conference call to
- Seattle starting September 1 and extends to all future instances.
-
- BEGIN:VCALENDAR
- METHOD:REQUEST
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:guid-1 at host1.com
- RECURRENCE-ID;THISANDFUTURE:19970901T210000Z
- SEQUENCE:3
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE:Mailto:C at example.com
- ATTENDEE;RSVP=TRUE:Mailto:D at 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:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:123456789 at host1.com
- SEQUENCE:4
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE:Mailto:C at example.com
- ATTENDEE;RSVP=TRUE:Mailto:D at example.com
- DESCRIPTION:IETF-C&S Conference Call
- CLASS:PUBLIC
-
-
-
-Silverberg, et. al. Standards Track [Page 82]
-
-RFC 2446 iTIP November 1998
-
-
- 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, but does not want
- to reschedule the entire meeting or lose any of the per-instance
- information already collected.
-
- The original event:
-
- BEGIN:VCALENDAR
- METHOD:REQUEST
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:123456789 at host1.com
- SEQUENCE:0
- RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- SUMMARY:Review Accounts
- DTSTART:19980303T210000Z
- DTEND:19980303T220000Z
- LOCATION:The White Room
- DTSTAMP:19980301T093000Z
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
- Assume that many other updates happen to this event and that a lot of
- instance-specific information exists in the recurring series. The
- "SEQUENCE" property value is 7 for the next update. Now the
- "Organizer" wants to add Thursdays to the event:
-
- BEGIN:VCALENDAR
- METHOD:ADD
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
-
-
-
-Silverberg, et. al. Standards Track [Page 83]
-
-RFC 2446 iTIP November 1998
-
-
- BEGIN:VEVENT
- UID:123456789 at host1.com
- SEQUENCE:7
- RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- SUMMARY:Review Accounts
- DTSTART:19980303T210000Z
- DTEND:19980303T220000Z
- DTSTAMP:19980303T193000Z
- LOCATION:The Usual conference room
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
- Alternatively, if the "Organizer" is not concerned with per-instance
- updates, 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.
-
- BEGIN:VCALENDAR
- METHOD:REQUEST
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:123456789 at host1.com
- SEQUENCE:7
- RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- SUMMARY:Review Accounts
- DTSTART:19980303T210000Z
- DTEND:19980303T220000Z
- DTSTAMP:19980303T193000Z
- LOCATION:The White Room
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
- 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
-
-
-
-Silverberg, et. al. Standards Track [Page 84]
-
-RFC 2446 iTIP November 1998
-
-
- changes and finally the "REFRESH".
-
- Original Request:
-
- BEGIN:VCALENDAR
- METHOD:REQUEST
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:123456789 at host1.com
- SEQUENCE:0
- RDATE:19980304T180000Z
- RDATE:19980311T180000Z
- RDATE:19980318T180000Z
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- SUMMARY:Review Accounts
- DTSTART:19980304T180000Z
- DTEND:19980304T200000Z
- DTSTAMP:19980303T193000Z
- LOCATION:Conference Room A
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
- Organizer changes 2nd instance Location and Time:
-
- BEGIN:VCALENDAR
- METHOD:REQUEST
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:123456789 at host1.com
- SEQUENCE:1
- RECURRENCE-ID:19980311T180000Z
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- SUMMARY:Review Accounts
- DTSTART:19980311T160000Z
- DTEND:19980311T180000Z
- DTSTAMP:19980306T193000Z
- LOCATION:The Small conference room
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-Silverberg, et. al. Standards Track [Page 85]
-
-RFC 2446 iTIP November 1998
-
-
- Organizer adds a 4th instance of the meeting using the "ADD" method
-
- BEGIN:VCALENDAR
- METHOD:ADD
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:123456789 at host1.com
- SEQUENCE:2
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- SUMMARY:Review Accounts
- DTSTART:19980315T180000Z
- DTEND:19980315T200000Z
- DTSTAMP:19980307T193000Z
- LOCATION:Conference Room A
- STATUS:CONFIRMED
- END:VEVENT
- END:VCALENDAR
-
- 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:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:123456789 at host1.com
- SEQUENCE:2
- RDATE:19980304T180000Z
- RDATE:19980311T160000Z
- RDATE:19980315T180000Z
- Error! Bookmark not defined.
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- SUMMARY:Review Accounts
- DTSTART:19980304T180000Z
- DTEND:19980304T200000Z
- DTSTAMP:19980303T193000Z
- LOCATION:Conference Room A
- STATUS:CONFIRMED
-
-
-
-Silverberg, et. al. Standards Track [Page 86]
-
-RFC 2446 iTIP November 1998
-
-
- END:VEVENT
-
- BEGIN:VEVENT
- Error! Bookmark not defined.
- SEQUENCE:2
- RECURRENCE-ID:19980311T160000Z
- Error! Bookmark not defined.
- ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined.
- ATTENDEE;Error! Bookmark not defined.
- SUMMARY:Review Accounts
- DTSTART:19980311T160000Z
- DTEND:19980304T180000Z
- DTSTAMP:19980306T193000Z
- LOCATION:The Small conference room
- STATUS:CONFIRMED
- END:VEVENT
-
- END:VCALENDAR
-
-4.4.8 Counter An Instance Of A Recurring Event
-
- In this example one of the "Attendees" counters the "DTSTART"
- property of the proposed second July meeting.
-
- BEGIN:VCALENDAR
- METHOD:COUNTER
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:guid-1 at host1.com
- RECURRENCE-ID:19970715T210000Z
- SEQUENCE:4
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;RSVP=TRUE:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE:Mailto:C at example.com
- ATTENDEE;RSVP=TRUE:Mailto:D at 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
-
-
-
-
-Silverberg, et. al. Standards Track [Page 87]
-
-RFC 2446 iTIP November 1998
-
-
-4.4.9 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:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:guid-1 at host1.com
- SEQUENCE:0
- RRULE:FREQ=MONTHLY;BYMONTHDAY=1
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE:Mailto:C at example.com
- ATTENDEE;RSVP=TRUE:Mailto:D at example.com
- DESCRIPTION:IETF-C&S Conference Call
- CLASS:PUBLIC
- SUMMARY:IETF Calendaring Working Group Meeting
- DTSTART:19970601T210000Z
- DTEND:19970601T220000Z
- DTSTAMP:19970602T094000Z
- LOCATION:Conference Call
- STATUS:CONFIRMED
- FOO:BAR
- END:VEVENT
- END:VCALENDAR
-
- Response from "B" to indicate that RRULE is not supported and an
- unrecognized property was encountered
-
- BEGIN:VCALENDAR
- PRODID:-//RDU Software//NONSGML HandCal//EN
- METHOD:REPLY
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE:Mailto:B at example.com
- REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single
- event;RRULE
- REQUEST-STATUS:3.0;Invalid Property Name;FOO
- UID:guid-1 at host1.com
- SEQUENCE:0
- DTSTAMP:19970603T094000Z
-
-
-
-Silverberg, et. al. Standards Track [Page 88]
-
-RFC 2446 iTIP November 1998
-
-
- 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.
-
-+--------------------------------------------------------------------+
-| Action | "Organizer" | Attendee |
-+--------------------------------------------------------------------+
-| Initiate a to-do | "A" sends a REQUEST | |
-| request | message to "B", "C",| |
-| | and "D" | |
-+--------------------------------------------------------------------+
-| Accept the to-do | | "B" sends a "REPLY" |
-| request | | message to "A" with its |
-| | | "partstat" paramater |
-| | | set to "accepted". |
-+--------------------------------------------------------------------+
-| Decline the to-do | | "C" sends a REPLY |
-| request | | message to "A" with its |
-| | | "partstat" parameter |
-| | | set to "declined". |
-+--------------------------------------------------------------------+
-| Tentatively accept | | "D" sends a REPLY |
-| the to-do request | | message to "A" with its |
-| | | "partstat" parameter |
-| | | set to "tentative". |
-+--------------------------------------------------------------------+
-| Check attendee | "A" sends a REQUEST | |
-| completion status | message to "B" and | |
-| | "D" with current | |
-| | information. | |
-+--------------------------------------------------------------------+
-| Attendee indicates | | "B" sends a "REPLY" |
-| percent complete | | message indicating |
-| | | percent complete |
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 89]
-
-RFC 2446 iTIP November 1998
-
-
-+--------------------------------------------------------------------+
-| Attendee indicates | | "D" sends a "REPLY" |
-| completion | | message indicating |
-| | | 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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VTODO
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE:Mailto:C at example.com
- ATTENDEE;RSVP=TRUE:Mailto:D at example.com
- DTSTART:19970701T170000Z
- DUE:19970722T170000Z
- PRIORITY:1
- SUMMARY:Create the requirements document
- UID:calsrv.example.com-873970198738777-00 at 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:-//ACME/DesktopCalendar//EN
- METHOD:REPLY
- VERSION:2.0
- BEGIN:VTODO
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B at example.com
- UID:calsrv.example.com-873970198738777-00 at example.com
- COMMENT:I'll send you my input by e-mail
- SEQUENCE:0
- DTSTAMP:19970717T203000Z
- REQUEST-STATUS:2.0;Success
-
-
-
-Silverberg, et. al. Standards Track [Page 90]
-
-RFC 2446 iTIP November 1998
-
-
- END:VTODO
- END:VCALENDAR
-
- "B" could have declined the TODO 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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VTODO
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D at example.com
- UID:calsrv.example.com-873970198738777-00 at 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:-//ACME/DesktopCalendar//EN
- METHOD:REPLY
- VERSION:2.0
- BEGIN:VTODO
- ORGANIZER:MAILTO:A at example.com
- ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B at example.com
- PERCENT-COMPLETE:75
- UID:calsrv.example.com-873970198738777-00 at example.com
- DTSTAMP:19970717T233000Z
- SEQUENCE:0
- END:VTODO
- END:VCALENDAR
-
-
-
-Silverberg, et. al. Standards Track [Page 91]
-
-RFC 2446 iTIP November 1998
-
-
-4.5.5 A Reply: Completed
-
- A reply indicating that "D" completed "D's" part of the assignment.
-
- BEGIN:VCALENDAR
- PRODID:-//ACME/DesktopCalendar//EN
- METHOD:REPLY
- VERSION:2.0
- BEGIN:VTODO
- ORGANIZER:MAILTO:A at example.com
- ATTENDEE;PARTSTAT=COMPLETED:Mailto:D at example.com
- UID:calsrv.example.com-873970198738777-00 at example.com
- DTSTAMP:19970717T233000Z
- SEQUENCE:0
- END:VTODO
- END:VCALENDAR
-
-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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VTODO
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B at example.com
- ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D at example.com
- DTSTART:19970701T170000Z
- DUE:19970722T170000Z
- PRIORITY:1
- SUMMARY:Create the requirements document
- UID:calsrv.example.com-873970198738777-00 at example.com
- SEQUENCE:1
- DTSTAMP:19970718T100000Z
- STATUS:IN-PROGRESS
- PERCENT-COMPLETE:40
- END:VTODO
- END:VCALENDAR
-
-4.5.7 Recurring VTODOs
-
- The following examples relate to recurring "VTODO" calendar
- components.
-
-
-
-
-Silverberg, et. al. Standards Track [Page 92]
-
-RFC 2446 iTIP November 1998
-
-
-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:-//ACME/DesktopCalendar//EN
- METHOD:REQUEST
- VERSION:2.0
- BEGIN:VTODO
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR:Mailto:A at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B at example.com
- ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D at example.com
- RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
- DTSTART:19980101T100000-0700
- DUE:19980103T100000-0700
- SUMMARY:Send Status Reports to Area Managers
- UID:calsrv.example.com-873970198738777-00 at example.com
- SEQUENCE:0
- DTSTAMP:19970717T200000Z
- STATUS:NEEDS ACTION
- PRIORITY:1
- END:VTODO
- END:VCALENDAR
-
-4.5.7.2 Calculating due dates in recurring VTODOs
-
- The due date in a recurring "VTODO" calendar component is either a
- fixed interval specified in the "REQUEST" method or specified using
- the "RECURRENCE-ID" property. The former is calculated by applying
- the difference between "DTSTART" and "DUE" properties and applying it
- to each of the start of each recurring instance. Hence, if the
- initial "VTODO" calendar component specifies a "DTSTART" property
- value of "19970701T190000Z" and a "DUE" property value of
- "19970801T190000Z" the interval of one day which is applied to each
- recurring instance of the "VTODO" calendar component to determine the
- "DUE" date of the instance.
-
-4.5.7.3 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:-//ACME/DesktopCalendar//EN
- METHOD:REPLY
- VERSION:2.0
-
-
-
-Silverberg, et. al. Standards Track [Page 93]
-
-RFC 2446 iTIP November 1998
-
-
- BEGIN:VTODO
- ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B at example.com
- PERCENT-COMPLETE:75
- UID:calsrv.example.com-873970198738777-00 at 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:-//ACME/DesktopCalendar//EN
- VERSION:2.0
- BEGIN:VJOURNAL
- DTSTART:19971002T200000Z
- ORGANIZER:MAILTO:A at 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 at example.com
- RELATED-TO:0981234-1234234-2402-35 at example.com
- ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt
- END:VJOURNAL
- END:VCALENDAR
-
-4.7 Other Examples
-
-4.7.1 Event Refresh
-
- Refresh the event with "UID" property value of "guid-1-
- 12345 at host1.com":
-
- BEGIN:VCALENDAR
- PRODID:-//RDU Software//NONSGML HandCal//EN
- METHOD:REFRESH
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE:Mailto:B at example.com
- ATTENDEE:Mailto:C at example.com
-
-
-
-Silverberg, et. al. Standards Track [Page 94]
-
-RFC 2446 iTIP November 1998
-
-
- ATTENDEE:Mailto:D at example.com
- UID: guid-1-12345 at host1.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 a request
- 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
- 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".
-
-
-
-
-Silverberg, et. al. Standards Track [Page 95]
-
-RFC 2446 iTIP November 1998
-
-
-+--------------------------------------------------------------------+
-| Action | "Organizer" | Attendee |
-+--------------------------------------------------------------------+
-| Update an instance | "A" sends "REQUEST"| |
-| request | message to "B" | |
-+--------------------------------------------------------------------+
-| Attendee requests | | "B" sends a "REFRESH" |
-| refresh because | | message to "A" |
-| "RECURRENCE-ID" was| | |
-| not found | | |
-+--------------------------------------------------------------------+
-| Refresh the entire | "A" sends the | |
-| Event | latest copy of the | |
-| | Event to "B" | |
-+--------------------------------------------------------------------+
-| Attendee handles | | "B" updates to the |
-| the request and | | latest copy of the |
-| updates the | | meeting. |
-| instance | | |
-+--------------------------------------------------------------------+
-
- Request from "A":
-
- BEGIN:VCALENDAR
- METHOD:REQUEST
- PRODID:-//RDU Software//NONSGML HandCal//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:acme-12345 at host1.com
- SEQUENCE:3
- RRULE:FREQ=WEEKLY
- RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z
- ORGANIZER:Mailto:A at example.com
- ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A at example.com
- ATTENDEE:Mailto:B at 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 "acme-12345 at host1.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
-
-
-
-Silverberg, et. al. Standards Track [Page 96]
-
-RFC 2446 iTIP November 1998
-
-
- 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:-//RDU Software//NONSGML HandCal//EN
- METHOD:REFRESH
- VERSION:2.0
- BEGIN:VEVENT
- ORGANIZER:Mailto:A at example.com
- ATTENDEE:Mailto:B at example.com
- UID:acme-12345 at host1.com
- DTSTAMP:19970603T094000
- END:VEVENT
- END:VCALENDAR
-
-5 Application Protocol Fallbacks
-
-5.1 Partial Implementation
-
- Applications that support this memo 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.
-
-5.1.1 Event-Related Fallbacks
-
-Method Fallback
--------------- -----------------------------------------------------
-PUBLISH Required
-REQUEST PUBLISH
-REPLY Required
-ADD Required
-CANCEL Required
-REFRESH Required
-COUNTER Reply with Not Supported
-DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise
- reply with Not Supported
-
-iCalendar
-Property Fallback
--------------- -----------------------------------------------------
-CALSCALE Ignore; assume GREGORIAN
-PRODID Ignore
-METHOD Required as described in the Method list above
-VERSION Ignore
-
-
-
-
-Silverberg, et. al. Standards Track [Page 97]
-
-RFC 2446 iTIP November 1998
-
-
-Event-Related
-Components Fallback
--------------- -----------------------------------------------------
-VALARM Reply with Not Supported
-VTIMEZONE Required if any DateTime value refers to a time zone.
-
-Component
-Property Fallback
--------------- -----------------------------------------------------
-ATTACH Ignore
-ATTENDEE Required if EVENT-REQUEST is not implemented;
- otherwise reply with Not Supported
-CATEGORIES Ignore
-CLASS Ignore
-COMMENT Ignore
-COMPLETED Ignore
-nCONTACT Ignore
-CREATED Ignore
-DESCRIPTION Required
-DURATION Reply with Not Supported
-DTSTAMP Required
-DTSTART Required
-DTEND Required
-EXDATE Ignore
-EXRULE Ignore Reply with Not Supported. If implemented,
- VTIMEZONE MUST also be implemented.
-GEO Ignore
-LAST-MODIFIED Ignore
-LOCATION Required
-ORGANIZER Ignore
-PRIORITY Ignore
-RELATED-TO Ignore
-RDATE Ignore
-RRULE Ignore. 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
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 98]
-
-RFC 2446 iTIP November 1998
-
-
-5.1.2 Free/Busy-Related Fallbacks
-
-Method Fallback
--------------- -----------------------------------------------------
-PUBLISH Implementations MAY ignore the METHOD type. The
- REQUEST-STATUS "3.14;Unsupported capability" MUST be
- returned.
-REQUEST Implementations MAY ignore the METHOD type. The
- REQUEST-STATUS "3.14;Unsupported capability" MUST be
- returned.
-REPLY Implementations MAY ignore the METHOD type. The
- REQUEST-STATUS "3.14;Unsupported capability" MUST be
- returned.
-
-
-iCalendar
-Property Fallback
--------------- -----------------------------------------------------
-CALSCALE Ignore; assume GREGORIAN.
-PRODID Ignore
-METHOD Required as described in the Method list above.
-VERSION Ignore
-
-
-Component
-Property Fallback
--------------- -----------------------------------------------------
-COMMENT Ignore
-CONTACT Ignore
-DTEND Required
-DTSTAMP Required
-DTSTART Required
-DURATION Required
-FREEBUSY Required
-ORGANIZER Ignore
-REQUEST-STATUS Ignore
-UID Required
-URL Ignore
-X- Ignore
-
-5.1.3 To-Do-Related Fallbacks
-
-Method Fallback
--------------- -----------------------------------------------------
-PUBLISH Required
-REQUEST PUBLISH
-REPLY Required
-ADD Required
-
-
-
-Silverberg, et. al. Standards Track [Page 99]
-
-RFC 2446 iTIP November 1998
-
-
-CANCEL Required
-REFRESH Required
-COUNTER Reply with Not Supported
-DECLINECOUNTER Required if VTODO - COUNTER is implemented; otherwise
- reply with Not Supported
-
-iCalendar
-Property Fallback
--------------- -----------------------------------------------------
-CALSCALE Ignore; assume GREGORIAN.
-PRODID Ignore
-METHOD Required as described in the Method list above.
-VERSION Ignore
-
-
-To-Do-Related
-Components Fallback
--------------- -----------------------------------------------------
-VALARM Reply with Not Supported
-VTIMEZONE Required if any DateTime value refers to a time zone.
-
-
-Component
-Property Fallback
--------------- -----------------------------------------------------
-ATTACH Ignore
-ATTENDEE Required if REQUEST is not implemented; otherwise
- ignore
-CATEGORIES Ignore
-CLASS Ignore
-COMMENT Ignore
-COMPLETED Required
-CONTACT Ignore
-CREATED Ignore
-DESCRIPTION Required
-DUE Required
-DURATION Ignore Reply with Not Supported
-DTSTAMP Required
-DTSTART Required
-EXDATE Ignore Reply with Not Supported
-EXRULE Ignore Reply with Not Supported. If implemented,
- VTIMEZONE MUST also be implemented.
-LAST-MODIFIED Ignore
-LOCATION Ignore
-ORGANIZER Ignore
-PERCENT-COMPLETE Ignore
-PRIORITY Required
-RECURRENCE-ID Ignore
-
-
-
-Silverberg, et. al. Standards Track [Page 100]
-
-RFC 2446 iTIP November 1998
-
-
-RELATED-TO Ignore
-REQUEST-STATUS Ignore
-RDATE Ignore
-RRULE Ignore. 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
-
-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
-Property Fallback
--------------- -----------------------------------------------------
-CALSCALE Ignore; assume GREGORIAN.
-PRODID Ignore
-METHOD Required as described in the Method list above.
-VERSION Ignore
-
-
-Journal-Related
-Components Fallback
--------------- -----------------------------------------------------
-VTIMEZONE Required if any DateTime value refers to a time zone.
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 101]
-
-RFC 2446 iTIP November 1998
-
-
-Component
-Property Fallback
--------------- -----------------------------------------------------
-ATTACH Ignore
-ATTENDEE Required if JOURNAL-REQUEST is implemented; otherwise
- ignore
-CATEGORIES Ignore
-CLASS Ignore
-COMMENT Ignore
-CONTACT Ignore
-CREATED Ignore
-DESCRIPTION Required
-DTSTAMP Required
-DTSTART Required
-EXDATE Ignore
-EXRULE Ignore Reply with Not Supported. If implemented,
- VTIMEZONE MUST also be implemented.
-LAST-MODIFIED Ignore
-ORGANIZER Ignore
-RECURRENCE-ID Ignore
-RELATED-TO Ignore
-RDATE Ignore.
-RRULE Ignore. 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 can not be correlated 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.
-
-
-
-Silverberg, et. al. Standards Track [Page 102]
-
-RFC 2446 iTIP November 1998
-
-
-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 an "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.
-
-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 which 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", "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"
- property and send it to the "Organizer". An iCalendar object that
-
-
-
-Silverberg, et. al. Standards Track [Page 103]
-
-RFC 2446 iTIP November 1998
-
-
- 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
-
- 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 MAY 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 block all
- the calendar's free time.
-
-6.1.6 Procedural Alarms
-
- The "REQUEST" methods for "VEVENT" and "VTODO" calendar components
- MAY contain "VALARM" calendar components. The "VALARM" calendar
- component may be of type "PROCEDURE" and MAY have an attachment
- containing an executable program. Implementations that incorporate
- these types of alarms are subject to any virus or malicious attack
- that may occur as a result of executing the attachment.
-
-6.1.7 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
- "Attendee's" 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 is subject to a high probability of attack,
- iTIP transactions SHOULD be encrypted. This may be accomplished using
- public key technology, specifically Security Multiparts for MIME
-
-
-
-Silverberg, et. al. Standards Track [Page 104]
-
-RFC 2446 iTIP November 1998
-
-
- [RFC-1847] in the iTIP transport binding. This helps mitigate the
- threats of spoofing, eavesdropping and malicious changes in transit.
-
-6.2.1 Use of [RFC-1847] to secure iTIP transactions
-
- iTIP transport bindings MUST provide a mechanism based on Security
- Multiparts for MIME [RFC-1847] to enable authentication of the
- sender's identity, and 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 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.
-
- Implementations MAY provide controls for users to disable this
- capability.
-
-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 malicious procedural alarms SHOULD be mitigated by a
- calendar system that uses this protocol by providing controls that
- may be used to disallow procedural alarms in iTIP transactions and/or
- remove all alarms from the object before delivery to the recipient.
-
- 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 User" 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.
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 105]
-
-RFC 2446 iTIP November 1998
-
-
-7 Acknowledgments
-
- A hearty thanks to the following individuals who have participated in
- the drafting, review and discussion of this memo:
-
- Anik Ganguly, Dan Hickman, Paul Hill, Daryl Huff, Bruce Kahn, Antoine
- Leca, Bob Mahoney, John Noerenberg, Leo Parker, John Rose, Doug
- Royer, Vinod Seraphin, Richard Shusterman, Derik Stenerson, John Sun,
- Alexander Taler, Kevin Tsurutome.
-
-8 Bibliography
-
- [iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and
- Scheduling Core Object Specification - iCalendar", RFC
- 2445, November 1998.
-
- [iMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
- Message-Based Interoperability Protocol - iMIP", RFC 2447,
- November 1998.
-
- [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [US-ASCII] Coded Character Set--7-bit American Standard Code for
- Information Interchange, ANSI X3.4-1986.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 106]
-
-RFC 2446 iTIP November 1998
-
-
-9 Authors' Addresses
-
- The following address information is provided in a vCard v3.0,
- Electronic Business Card, format.
-
- The authors of this memo are:
-
- BEGIN:VCARD
- VERSION:3.0
- N:Dawson;Frank
- FN:Frank Dawson
- ORG:Lotus Development Corporation
- ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613-
- 3502;USA
- TEL;TYPE=WORK,MSG:+1-919-676-9515
- TEL;TYPE=WORK,FAX:+1-919-676-9564
- EMAIL;TYPE=PREF,INTERNET:Frank_Dawson at Lotus.com
- EMAIL;TYPE=INTERNET:fdawson at earthlink.net
- URL:http://home.earthlink.net/~fdawson
- END:VCARD
-
- BEGIN:VCARD
- VERSION:3.0
- N:Hopson;Ross
- FN:Ross Hopson
- ORG:On Technology, Inc.
- ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 1600;434 Fayetteville St.
- Mall\, Two Hannover Square;Raleigh;NC;27601
- TEL;TYPE=WORK,MSG:+1-919-890-4036
- TEL;TYPE=WORK,FAX:+1-919-890-4100
- EMAIL;TYPE=INTERNET:rhopson at on.com
- END:VCARD
-
- BEGIN:VCARD
- VERSION:3.0
- N:Mansour;Steve
- FN:Steve Mansour
- ORG:Netscape Communications Corporation
- ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain
- View;CA;94043;USA
- TEL;TYPE=WORK,MSG:+1-650-937-2378
- TEL;TYPE=WORK,FAX:+1-650-937-2103
- EMAIL;TYPE=INTERNET:sman at netscape.com
- END:VCARD
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 107]
-
-RFC 2446 iTIP November 1998
-
-
- BEGIN:VCARD
- VERSION:3.0
- N:Silverberg;Steve
- FN:Steve Silverberg
- ORG:Microsoft Corporation
- ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
- Redmond;WA;98052-6399;USA
- TEL;TYPE=WORK,MSG:+1-425-936-9277
- TEL;TYPE=WORK,FAX:+1-425-936-8019
- EMAIL;INTERNET:stevesil at Microsoft.com
- END:VCARD
-
- The iCalendar object is a result of the work of the Internet
- Engineering Task Force Calendaring and scheduling Working Group. The
- chairman of that working group is:
-
- BEGIN:VCARD
- VERSION:3.0
- N:Ganguly;Anik
- FN:Anik Ganguly
- ORG:Open Text Inc.
- ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
- Livonia;MI;48152;USA
- TEL;TYPE=WORK,MSG:+1-734-542-5955
- EMAIL;TYPE=INTERNET:ganguly at acm.org
- END:VCARD
-
- The co-chairman of that working group is:
-
- BEGIN:VCARD
- VERSION:3.0
- N:Moskowitz;Robert
- FN:Robert Moskowitz
- NICKNAME:Bob
- EMAIL; TYPE=INTERNET:rgm-ietf at htt-consult.com
- END:VCARD
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 108]
-
-RFC 2446 iTIP November 1998
-
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Silverberg, et. al. Standards Track [Page 109]
-
Added: CalendarServer/trunk/doc/RFC/rfc5546-iTIP.txt
===================================================================
--- CalendarServer/trunk/doc/RFC/rfc5546-iTIP.txt (rev 0)
+++ CalendarServer/trunk/doc/RFC/rfc5546-iTIP.txt 2010-04-27 20:51:51 UTC (rev 5538)
@@ -0,0 +1,7451 @@
+
+
+
+
+
+
+Network Working Group C. Daboo, Ed.
+Request for Comments: 5546 Apple Inc.
+Obsoletes: 2446 December 2009
+Updates: 5545
+Category: Standards Track
+
+
+ iCalendar Transport-Independent Interoperability Protocol (iTIP)
+
+Abstract
+
+ This document specifies a protocol that uses the iCalendar object
+ specification to provide scheduling interoperability between
+ different calendaring systems. This is done without reference to a
+ specific transport protocol so as to allow multiple methods of
+ communication between systems. Subsequent documents will define
+ profiles of this protocol that use specific, interoperable methods of
+ communication between systems.
+
+ The iCalendar Transport-Independent Interoperability Protocol (iTIP)
+ complements the iCalendar object specification by adding semantics
+ for group scheduling methods commonly available in current
+ calendaring systems. These scheduling methods permit two or more
+ calendaring systems to perform transactions such as publishing,
+ scheduling, rescheduling, responding to scheduling requests,
+ negotiating changes, or canceling.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+
+
+
+
+
+Daboo Standards Track [Page 1]
+
+RFC 5546 iTIP December 2009
+
+
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction and Overview .......................................5
+ 1.1. Formatting Conventions .....................................5
+ 1.2. Related Documents ..........................................6
+ 1.3. Roles ......................................................6
+ 1.4. Methods ....................................................7
+ 2. Interoperability Models .........................................9
+ 2.1. Application Protocol ......................................10
+ 2.1.1. Scheduling State ...................................10
+ 2.1.2. Delegation .........................................10
+ 2.1.3. Acting on Behalf of Other Calendar Users ...........11
+ 2.1.4. Component Revisions ................................11
+ 2.1.5. Message Sequencing .................................12
+ 3. Application Protocol Elements ..................................13
+ 3.1. Common Component Restriction Tables .......................15
+ 3.1.1. VCALENDAR ..........................................15
+ 3.1.2. VTIMEZONE ..........................................15
+ 3.1.3. VALARM .............................................17
+ 3.2. Methods for VEVENT Calendar Components ....................17
+ 3.2.1. PUBLISH ............................................18
+ 3.2.2. REQUEST ............................................20
+ 3.2.3. REPLY ..............................................25
+ 3.2.4. ADD ................................................27
+ 3.2.5. CANCEL .............................................29
+ 3.2.6. REFRESH ............................................31
+ 3.2.7. COUNTER ............................................33
+ 3.2.8. DECLINECOUNTER .....................................35
+ 3.3. Methods for VFREEBUSY Components ..........................37
+ 3.3.1. PUBLISH ............................................37
+ 3.3.2. REQUEST ............................................40
+ 3.3.3. REPLY ..............................................42
+
+
+
+Daboo Standards Track [Page 2]
+
+RFC 5546 iTIP December 2009
+
+
+ 3.4. Methods for VTODO Components ..............................44
+ 3.4.1. PUBLISH ............................................44
+ 3.4.2. REQUEST ............................................46
+ 3.4.3. REPLY ..............................................51
+ 3.4.4. ADD ................................................53
+ 3.4.5. CANCEL .............................................55
+ 3.4.6. REFRESH ............................................57
+ 3.4.7. COUNTER ............................................59
+ 3.4.8. DECLINECOUNTER .....................................61
+ 3.5. Methods for VJOURNAL Components ...........................62
+ 3.5.1. PUBLISH ............................................63
+ 3.5.2. ADD ................................................64
+ 3.5.3. CANCEL .............................................66
+ 3.6. Status Replies ............................................68
+ 3.7. Implementation Considerations .............................77
+ 3.7.1. Working With Recurrence Instances ..................77
+ 3.7.2. Attendee Property Considerations ...................78
+ 3.7.3. Extension Tokens ...................................79
+ 4. Examples .......................................................79
+ 4.1. Published Event Examples ..................................79
+ 4.1.1. A Minimal Published Event ..........................80
+ 4.1.2. Changing a Published Event .........................80
+ 4.1.3. Canceling a Published Event ........................81
+ 4.1.4. A Rich Published Event .............................81
+ 4.1.5. Anniversaries or Events Attached to Entire Days ....83
+ 4.2. Group Event Examples ......................................83
+ 4.2.1. A Group Event Request ..............................84
+ 4.2.2. Reply to a Group Event Request .....................85
+ 4.2.3. Update an Event ....................................85
+ 4.2.4. Countering an Event Proposal .......................86
+ 4.2.5. Delegating an Event ................................88
+ 4.2.6. Delegate Accepts the Meeting .......................90
+ 4.2.7. Delegate Declines the Meeting ......................91
+ 4.2.8. Forwarding an Event Request ........................92
+ 4.2.9. Cancel a Group Event ...............................92
+ 4.2.10. Removing Attendees ................................93
+ 4.2.11. Replacing the Organizer ...........................95
+ 4.3. Busy Time Examples ........................................96
+ 4.3.1. Publish Busy Time ..................................96
+ 4.3.2. Request Busy Time ..................................96
+ 4.3.3. Reply to a Busy Time Request .......................97
+ 4.4. Recurring Event and Time Zone Examples ....................98
+ 4.4.1. A Recurring Event Spanning Time Zones ..............98
+ 4.4.2. Modify a Recurring Instance ........................99
+ 4.4.3. Cancel an Instance ................................101
+ 4.4.4. Cancel a Recurring Event ..........................101
+ 4.4.5. Change All Future Instances .......................102
+ 4.4.6. Add a New Instance to a Recurring Event ...........102
+
+
+
+Daboo Standards Track [Page 3]
+
+RFC 5546 iTIP December 2009
+
+
+ 4.4.7. Add a New Series of Instances to a
+ Recurring Event ...................................103
+ 4.4.8. Refreshing a Recurring Event ......................104
+ 4.4.9. Counter an Instance of a Recurring Event ..........106
+ 4.4.10. Error Reply to a Request .........................107
+ 4.5. Group To-Do Examples .....................................108
+ 4.5.1. A VTODO Request ...................................109
+ 4.5.2. A VTODO Reply .....................................110
+ 4.5.3. A VTODO Request for Updated Status ................110
+ 4.5.4. A Reply: Percent-Complete .........................111
+ 4.5.5. A Reply: Completed ................................111
+ 4.5.6. An Updated VTODO Request ..........................112
+ 4.5.7. Recurring VTODOs ..................................112
+ 4.6. Journal Examples .........................................113
+ 4.7. Other Examples ...........................................114
+ 4.7.1. Event Refresh .....................................114
+ 4.7.2. Bad RECURRENCE-ID .................................114
+ 5. Application Protocol Fallbacks ................................116
+ 5.1. Partial Implementation ...................................116
+ 5.1.1. Event-Related Fallbacks ...........................117
+ 5.1.2. Free/Busy-Related Fallbacks .......................119
+ 5.1.3. To-Do-Related Fallbacks ...........................120
+ 5.1.4. Journal-Related Fallbacks .........................122
+ 5.2. Latency Issues ...........................................123
+ 5.2.1. Cancellation of an Unknown Calendar Component .....123
+ 5.2.2. Unexpected Reply from an Unknown Delegate .........124
+ 5.3. Sequence Number ..........................................124
+ 6. Security Considerations .......................................124
+ 6.1. Security Threats .........................................124
+ 6.1.1. Spoofing the Organizer ............................124
+ 6.1.2. Spoofing the Attendee .............................124
+ 6.1.3. Unauthorized Replacement of the Organizer .........125
+ 6.1.4. Eavesdropping and Data Integrity ..................125
+ 6.1.5. Flooding a Calendar ...............................125
+ 6.1.6. Unauthorized REFRESH Requests .....................125
+ 6.2. Recommendations ..........................................125
+ 6.2.1. Securing iTIP transactions ........................125
+ 6.2.2. Implementation Controls ...........................126
+ 6.2.3. Access Controls and Filtering .....................126
+ 6.3. Privacy Issues ...........................................126
+ 7. IANA Considerations ...........................................127
+ 7.1. Registration Template for REQUEST-STATUS Values ..........127
+ 7.2. Additions to iCalendar METHOD Registry ...................127
+ 7.3. REQUEST-STATUS Value Registry ............................129
+ 8. Acknowledgments ...............................................130
+ 9. References ....................................................131
+ 9.1. Normative References .....................................131
+ 9.2. Informative References ...................................131
+
+
+
+Daboo Standards Track [Page 4]
+
+RFC 5546 iTIP December 2009
+
+
+ Appendix A. Differences from RFC 2446 ...........................132
+ A.1. Changed Restrictions .....................................132
+ A.2. Deprecated Features ......................................133
+
+1. Introduction and Overview
+
+ This document specifies how calendaring systems use iCalendar
+ [RFC5545] objects to interoperate with other calendaring systems. In
+ particular, it specifies how to schedule events, to-dos, or daily
+ journal entries. It further specifies how to search for available
+ busy time information. It does so in a general way, without
+ specifying how communication between different systems actually takes
+ place. Subsequent documents will specify transport bindings between
+ systems that use this protocol.
+
+ This protocol is based on messages sent from an originator to one or
+ more recipients. For certain types of messages, a recipient may
+ reply in order to update their status and may also return
+ transaction/request status information. The protocol supports the
+ ability for the message originator to modify or cancel the original
+ message. The protocol also supports the ability for recipients to
+ suggest changes to the originator of a message. The elements of the
+ protocol also define the user roles for its transactions.
+
+ This specification obsoletes RFC 2446 - a list of important changes
+ is provided in Appendix A.
+
+1.1. Formatting Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ Calendaring and scheduling roles are referred to in quoted-strings of
+ text with the first character of each word in upper case. For
+ example, "Organizer" refers to a role of a "Calendar User" (CU)
+ within the scheduling protocol.
+
+ Calendar components defined by [RFC5545] are referred to with
+ capitalized, quoted-strings of text. All calendar components start
+ with the letter "V". For example, "VEVENT" refers to the event
+ calendar component, "VTODO" refers to the to-do calendar component,
+ and "VJOURNAL" refers to the daily journal calendar component.
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 5]
+
+RFC 5546 iTIP December 2009
+
+
+ Scheduling methods are referred to with capitalized, quoted-strings
+ of text. For example, "REQUEST" refers to the method for requesting
+ a scheduling calendar component be created or modified; "REPLY"
+ refers to the method a recipient of a request uses to update their
+ status with the "Organizer" of the calendar component.
+
+ Properties defined by [RFC5545] are referred to with capitalized,
+ quoted-strings of text, followed by the word "property". For
+ example, "ATTENDEE" property refers to the iCalendar property used to
+ convey the calendar address of a "Calendar User".
+
+ Property parameters defined by this specification are referred to
+ with capitalized, quoted-strings of text, followed by the word
+ "parameter". For example, "VALUE" parameter refers to the iCalendar
+ property parameter used to override the default data type for a
+ property value.
+
+ Enumerated values defined by this specification are referred to with
+ capitalized text, either alone or followed by the word "value".
+
+ In tables, the quoted-string text is specified without quotes in
+ order to minimize the table length.
+
+1.2. Related Documents
+
+ Implementers will need to be familiar with several other
+ specifications that, along with this one, describe the Internet
+ calendaring and scheduling standards. The related documents are:
+
+ [RFC5545] - specifies the objects, data types, properties, and
+ property parameters used in the protocols, along with the methods
+ for representing and encoding them.
+
+ [iMIP] - specifies an Internet email binding for iTIP.
+
+ This specification does not attempt to repeat the concepts or
+ definitions from these other specifications. Where possible,
+ explicit references are made to the other specifications.
+
+1.3. Roles
+
+ Exchanges of iCalendar objects for the purposes of group calendaring
+ and scheduling occur between "Calendar Users" (CUs). CUs take on
+ several roles in iTIP:
+
+
+
+
+
+
+
+Daboo Standards Track [Page 6]
+
+RFC 5546 iTIP December 2009
+
+
+ +-----------+-------------------------------------------------------+
+ | Role | Description |
+ +-----------+-------------------------------------------------------+
+ | Organizer | The CU who initiates an exchange takes on the role of |
+ | | Organizer. For example, the CU who proposes a group |
+ | | meeting is the Organizer. |
+ | | |
+ | Attendee | CUs who are included in the scheduling message as |
+ | | possible recipients of that scheduling message. For |
+ | | example, the CUs asked to participate in a group |
+ | | meeting by the Organizer take on the role of |
+ | | Attendee. |
+ | | |
+ | Other CU | A CU that is not explicitly included in a scheduling |
+ | | message, i.e., not the Organizer or an Attendee. |
+ +-----------+-------------------------------------------------------+
+
+ Note that "ROLE" is also a descriptive parameter to the iCalendar
+ "ATTENDEE" property. Its use is to convey descriptive context about
+ an "Attendee" -- such as "chair", "required participant", or "non-
+ required participant" -- and has nothing to do with the calendaring
+ workflow.
+
+1.4. Methods
+
+ The iTIP methods are listed below and their usage and semantics are
+ defined in Section 3 of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 7]
+
+RFC 5546 iTIP December 2009
+
+
+ +----------------+--------------------------------------------------+
+ | Method | Description |
+ +----------------+--------------------------------------------------+
+ | PUBLISH | Used to publish an iCalendar object to one or |
+ | | more "Calendar Users". There is no |
+ | | interactivity between the publisher and any |
+ | | other "Calendar User". An example might include |
+ | | a baseball team publishing its schedule to the |
+ | | public. |
+ | | |
+ | REQUEST | Used to schedule an iCalendar object with other |
+ | | "Calendar Users". Requests are interactive in |
+ | | that they require the receiver to respond using |
+ | | the reply methods. Meeting requests, busy-time |
+ | | requests, and the assignment of tasks to other |
+ | | "Calendar Users" are all examples. Requests are |
+ | | also used by the Organizer to update the status |
+ | | of an iCalendar object. |
+ | | |
+ | REPLY | A reply is used in response to a request to |
+ | | convey Attendee status to the Organizer. |
+ | | Replies are commonly used to respond to meeting |
+ | | and task requests. |
+ | | |
+ | ADD | Add one or more new instances to an existing |
+ | | recurring iCalendar object. |
+ | | |
+ | CANCEL | Cancel one or more instances of an existing |
+ | | iCalendar object. |
+ | | |
+ | REFRESH | Used by an Attendee to request the latest |
+ | | version of an iCalendar object. |
+ | | |
+ | COUNTER | Used by an Attendee to negotiate a change in an |
+ | | iCalendar object. Examples include the request |
+ | | to change a proposed event time or change the |
+ | | due date for a task. |
+ | | |
+ | DECLINECOUNTER | Used by the Organizer to decline the proposed |
+ | | counter proposal. |
+ +----------------+--------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 8]
+
+RFC 5546 iTIP December 2009
+
+
+ Group scheduling in iTIP is accomplished using the set of "request"
+ and "response" methods described above. The following table shows
+ the methods broken down by who can send them.
+
+ +------------+------------------------------------------------------+
+ | Originator | Methods |
+ +------------+------------------------------------------------------+
+ | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER |
+ | | |
+ | Attendee | REPLY, REFRESH, COUNTER, REQUEST (only when |
+ | | delegating) |
+ +------------+------------------------------------------------------+
+
+ Note that for some calendar component types, the allowable methods
+ are a subset of the above set. In addition, apart from "VTIMEZONE"
+ iCalendar components, only one component type is allowed in a single
+ iTIP message.
+
+2. Interoperability Models
+
+ There are two distinct protocols relevant to interoperability: an
+ "application protocol" and a "transport protocol". The application
+ protocol defines the content of the iCalendar objects sent between
+ sender and receiver to accomplish the scheduling transactions listed
+ above. The transport protocol defines how the iCalendar objects are
+ sent between the sender and receiver. This document focuses on the
+ application protocol. Binding documents such as [iMIP] focus on the
+ transport protocol.
+
+ The connection between sender and receiver in the diagram below
+ refers to the application protocol. The iCalendar objects passed
+ from the sender to the receiver are presented in Section 3,
+ "Application Protocol Elements".
+
+ +----------+ +----------+
+ | | iTIP | |
+ | Sender |<-------------->| Receiver |
+ | | | |
+ +----------+ +----------+
+
+ There are several variations of this diagram in which the sender and
+ receiver take on various roles of a "Calendar User Agent" (CUA) or a
+ "Calendar Service" (CS).
+
+ The architecture of iTIP is depicted in the diagram below. An
+ application written to this specification may work with bindings for
+ the store-and-forward transport, the real-time transport, or both.
+ Also note that iTIP could be bound to other transports.
+
+
+
+Daboo Standards Track [Page 9]
+
+RFC 5546 iTIP December 2009
+
+
+ +--------------------------------------------------------+
+ | iTIP Protocol |
+ +--------------------------------------------------------+
+ | Transport |
+ + - - - - - + - - - - - - + - - - - - +
+ | Real-Time | Store-and-Forward | Others |
+ +-----------------+--------------------+-----------------+
+
+2.1. Application Protocol
+
+ In the iTIP model, an iCalendar object is created and managed by an
+ "Organizer". The "Organizer" interacts with other CUs by sending one
+ or more of the iTIP messages listed above. "Attendees" use the
+ "REPLY" method to communicate their status. "Attendees" do not make
+ direct changes to the master iCalendar object. They can, however,
+ use the "COUNTER" method to suggest changes to the "Organizer". In
+ any case, the "Organizer" has complete control over the master
+ iCalendar object.
+
+2.1.1. Scheduling State
+
+ There are two distinct states relevant to iCalendar objects used in
+ scheduling: the overall state of the iCalendar object and the state
+ associated with an "Attendee" in that iCalendar object.
+
+ The state of an iCalendar object is defined by the "STATUS" property
+ and is controlled by the "Organizer." There is no default value for
+ the "STATUS" property. The "Organizer" sets the "STATUS" property to
+ the appropriate value for each iCalendar object.
+
+ The state of a particular "Attendee" relative to an iCalendar object
+ used for scheduling is defined by the "PARTSTAT" parameter in the
+ "ATTENDEE" property for each "Attendee". When an "Organizer" issues
+ the initial iCalendar object, "Attendee" status is typically unknown.
+ The "Organizer" specifies this by setting the "PARTSTAT" parameter to
+ "NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" property
+ "PARTSTAT" parameter to an appropriate value as part of a "REPLY"
+ message sent back to the "Organizer".
+
+2.1.2. Delegation
+
+ Delegation is defined as the process by which an "Attendee" grants
+ another CU (or several CUs) the right to attend on their behalf. The
+ "Organizer" is made aware of this change because the delegating
+ "Attendee" informs the "Organizer". These steps are detailed in the
+ "REQUEST" method sections for the appropriate components.
+
+
+
+
+
+Daboo Standards Track [Page 10]
+
+RFC 5546 iTIP December 2009
+
+
+2.1.3. Acting on Behalf of Other Calendar Users
+
+ In many organizations, one user will act on behalf of another to
+ organize and/or respond to meeting requests. iTIP provides two
+ mechanisms that support these activities.
+
+ First, the "Organizer" is treated as a special entity, separate from
+ "Attendees". All responses from "Attendees" flow to the "Organizer",
+ making it easy to separate a "Calendar User" organizing a meeting
+ from "Calendar Users" attending the meeting. Additionally, iCalendar
+ provides descriptive roles for each "Attendee". For instance, a role
+ of "chair" may be ascribed to one or more "Attendees". The "chair"
+ and the "Organizer" may or may not be the same "Calendar User". This
+ maps well to scenarios where an assistant may manage meeting
+ logistics for another individual who chairs a meeting.
+
+ Second, a "SENT-BY" parameter may be specified in either the
+ "Organizer" or "Attendee" properties. When specified, the "SENT-BY"
+ parameter indicates that the responding CU acted on behalf of the
+ specified "Attendee" or "Organizer".
+
+2.1.4. Component Revisions
+
+ The "SEQUENCE" property is used by the "Organizer" to indicate
+ revisions to the calendar component. When the "Organizer" makes
+ changes to one of the following properties, the sequence number MUST
+ be incremented:
+
+ o "DTSTART"
+
+ o "DTEND"
+
+ o "DURATION"
+
+ o "DUE"
+
+ o "RRULE"
+
+ o "RDATE"
+
+ o "EXDATE"
+
+ o "STATUS"
+
+ In addition, changes made by the "Organizer" to other properties MAY
+ also require the sequence number to be incremented. The "Organizer"
+ CUA MUST increment the sequence number whenever it makes changes to
+ properties in the calendar component that the "Organizer" deems will
+
+
+
+Daboo Standards Track [Page 11]
+
+RFC 5546 iTIP December 2009
+
+
+ jeopardize the validity of the participation status of the
+ "Attendees". For example, changing the location of a meeting from
+ one location to another distant location could effectively impact the
+ participation status of the "Attendees".
+
+ Depending on the "METHOD", the "SEQUENCE" property MUST follow these
+ rules in the context of iTIP:
+
+ o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
+ value is incremented according to the rules stated above.
+
+ o The "SEQUENCE" property value MUST be incremented each time the
+ "Organizer" uses the "ADD" or "CANCEL" methods.
+
+ o The "SEQUENCE" property value MUST NOT be incremented when using
+ "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
+ delegation "REQUEST".
+
+ In some circumstances, the "Organizer" may not have received
+ responses to the final revision sent out. In this situation, the
+ "Organizer" may wish to send an update "REQUEST" and set "RSVP=TRUE"
+ for all "Attendees" so that current responses can be collected.
+
+ The value of the "SEQUENCE" property contained in a response from an
+ "Attendee" may not always match the "Organizer's" revision.
+ Implementations may choose to have the CUA indicate to the CU that
+ the response is to an iCalendar object that has been revised, and
+ allow the CU to decide whether or not to accept the response.
+
+ Whilst a change in sequence number is indicative of a significant
+ change to a previously scheduled item, "Attendee" CUAs SHOULD NOT
+ rely solely on a change in sequence number as a means of detecting a
+ significant change. Instead, CUAs SHOULD compare the old and new
+ versions of the calendar components, determine the exact nature of
+ the changes, and make decisions -- possibly based on "Calendar User"
+ preferences -- as to whether the user needs to be explicitly informed
+ of the change.
+
+2.1.5. Message Sequencing
+
+ CUAs that handle the iTIP application protocol must often correlate a
+ component in a calendar store with a component received in the iTIP
+ message. For example, an event may be updated with a later revision
+ of the same event. To accomplish this, a CUA must correlate the
+ version of the event already in its calendar store with the version
+ sent in the iTIP message. In addition to this correlation, there are
+ several factors that can cause iTIP messages to arrive in an
+ unexpected order. That is, an "Organizer" could receive a reply to
+
+
+
+Daboo Standards Track [Page 12]
+
+RFC 5546 iTIP December 2009
+
+
+ an earlier revision of a component after receiving a reply to a later
+ revision.
+
+ To maximize interoperability and to handle messages that arrive in an
+ unexpected order, use the following rules:
+
+ 1. The primary key for referencing a particular iCalendar component
+ is the "UID" property value. To reference an instance of a
+ recurring component, the primary key is composed of the "UID" and
+ the "RECURRENCE-ID" properties.
+
+ 2. The secondary key for referencing a component is the "SEQUENCE"
+ property value. For components where the "UID" and
+ "RECURRENCE-ID" property values are the same, the component with
+ the highest numeric value for the "SEQUENCE" property obsoletes
+ all other revisions of the component with lower values.
+
+ 3. "Attendees" send "REPLY" messages to the "Organizer". For
+ replies where the "UID" and "RECURRENCE-ID" property values are
+ the same, the value of the "SEQUENCE" property indicates the
+ revision of the component to which the "Attendee" is replying.
+ The reply with the highest numeric value for the "SEQUENCE"
+ property obsoletes all other replies with lower values.
+
+ 4. In situations where the "UID", "RECURRENCE-ID", and "SEQUENCE"
+ property values match, the "DTSTAMP" property is used as the tie-
+ breaker. The component with the latest "DTSTAMP" overrides all
+ others. Similarly, for "Attendee" responses where the "UID",
+ "RECURRENCE-ID", and "SEQUENCE" property values match, the
+ response with the latest "DTSTAMP" overrides all others.
+
+ Hence, CUAs will need to persist the following component properties
+ in order to correctly process iTIP messages: "UID", "RECURRENCE-ID",
+ "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property
+ of a component, "Organizer" CUAs will need to persist the "SEQUENCE"
+ and "DTSTAMP" property values associated with the "Attendee's" last
+ response, so that any earlier responses from an "Attendee" that are
+ received out of order (e.g., due to a delay in the transport) can be
+ correctly discarded.
+
+3. Application Protocol Elements
+
+ iTIP messages are "text/calendar" MIME entities that contain
+ calendaring and scheduling information. The particular type of
+ iCalendar message is referred to as the "method type". Each method
+ type is identified by a "METHOD" property specified as part of the
+ "text/calendar" content type. The table below shows various
+
+
+
+
+Daboo Standards Track [Page 13]
+
+RFC 5546 iTIP December 2009
+
+
+ combinations of calendar components and the method types that this
+ specification supports.
+
+ +----------------+--------+-------+----------+-----------+
+ | | VEVENT | VTODO | VJOURNAL | VFREEBUSY |
+ +----------------+--------+-------+----------+-----------+
+ | PUBLISH | Yes | Yes | Yes | Yes |
+ | REQUEST | Yes | Yes | No | Yes |
+ | REFRESH | Yes | Yes | No | No |
+ | CANCEL | Yes | Yes | Yes | No |
+ | ADD | Yes | Yes | Yes | No |
+ | REPLY | Yes | Yes | No | Yes |
+ | COUNTER | Yes | Yes | No | No |
+ | DECLINECOUNTER | Yes | Yes | No | No |
+ +----------------+--------+-------+----------+-----------+
+
+ Each method type is defined in terms of its associated components and
+ properties. Some components and properties are required, some are
+ optional, and others are excluded. The restrictions are expressed in
+ this document using a simple "restriction table". The first column
+ indicates the name of a component or property. Properties of the
+ iCalendar object are not indented. Properties of a component are
+ indented. The second column (the "Presence" column) indicates
+ whether or not a component or property should be present and, if
+ present, how many times it can occur. The third column contains
+ comments for further clarification.
+
+ The presence column uses the following values to assert whether a
+ property is required or optional, and the number of times it may
+ appear in the iCalendar object.
+
+ +----------------+--------------------------------------------------+
+ | Presence Value | Description |
+ +----------------+--------------------------------------------------+
+ | 1 | One instance MUST be present. |
+ | 1+ | At least one instance MUST be present. |
+ | 0 | Instances of this property MUST NOT be present. |
+ | 0+ | Multiple instances MAY be present. |
+ | 0 or 1 | Up to 1 instance of this property MAY be |
+ | | present. |
+ +----------------+--------------------------------------------------+
+
+ The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA-
+ COMPONENT", and "X-COMPONENT" to show where registered and
+ experimental property and component extensions can appear. The
+ tables do not lay out the restrictions of property parameters. Those
+ restrictions are defined in [RFC5545].
+
+
+
+
+Daboo Standards Track [Page 14]
+
+RFC 5546 iTIP December 2009
+
+
+3.1. Common Component Restriction Tables
+
+3.1.1. VCALENDAR
+
+ The restriction table below applies to properties of the iCalendar
+ object. That is, the properties at the outermost scope.
+
+ +-----------------------------------------------------+
+ | Constraints for Properties in a VCALENDAR Component |
+ +-----------------------------------------------------+
+
+ +--------------------+----------+--------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+--------------------+
+ | CALSCALE | 0 or 1 | |
+ | PRODID | 1 | |
+ | VERSION | 1 | Value MUST be 2.0. |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ +--------------------+----------+--------------------+
+
+3.1.2. VTIMEZONE
+
+ "VTIMEZONE" components may be referred to by other components via a
+ "TZID" parameter on a "DATETIME" value type. The property
+ restrictions in the table below apply to any "VTIMEZONE" component in
+ an iTIP message.
+
+ +--------------------------------------+
+ | Constraints for VTIMEZONE Components |
+ +--------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 15]
+
+RFC 5546 iTIP December 2009
+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to timezone. |
+ | DAYLIGHT | 0+ | MUST be one or more of either |
+ | | | STANDARD or DAYLIGHT. |
+ | COMMENT | 0+ | |
+ | DTSTART | 1 | MUST be local time format. |
+ | RDATE | 0+ | |
+ | RRULE | 0 or 1 | |
+ | TZNAME | 0+ | |
+ | TZOFFSETFROM | 1 | |
+ | TZOFFSETTO | 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | STANDARD | 0+ | MUST be one or more of either |
+ | | | STANDARD or DAYLIGHT. |
+ | COMMENT | 0+ | |
+ | DTSTART | 1 | MUST be local time format. |
+ | RDATE | 0+ | If present, RRULE MUST NOT be |
+ | | | present. |
+ | RRULE | 0 or 1 | If present, RDATE MUST NOT be |
+ | | | present. |
+ | TZNAME | 0+ | |
+ | TZOFFSETFROM | 1 | |
+ | TZOFFSETTO | 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | TZID | 1 | |
+ | TZURL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 16]
+
+RFC 5546 iTIP December 2009
+
+
+3.1.3. VALARM
+
+ The property restrictions in the table below apply to any "VALARM"
+ component in an iTIP message.
+
+ +-----------------------------------+
+ | Constraints for VALARM Components |
+ +-----------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | VALARM | 0+ | |
+ | ACTION | 1 | |
+ | ATTACH | 0+ | |
+ | ATTENDEE | 0+ | |
+ | DESCRIPTION | 0 or 1 | |
+ | DURATION | 0 or 1 | If present, REPEAT MUST be |
+ | | | present. |
+ | REPEAT | 0 or 1 | If present, DURATION MUST be |
+ | | | present. |
+ | SUMMARY | 0 or 1 | |
+ | TRIGGER | 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ +--------------------+----------+-----------------------------------+
+
+3.2. Methods for VEVENT Calendar Components
+
+ This section defines the property set restrictions for the method
+ types that are applicable to the "VEVENT" calendar component. Each
+ method is defined using a table that clarifies the property
+ constraints that define the particular method.
+
+ The following summarizes the methods that are defined for the
+ "VEVENT" calendar component.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 17]
+
+RFC 5546 iTIP December 2009
+
+
+ +----------------+--------------------------------------------------+
+ | Method | Description |
+ +----------------+--------------------------------------------------+
+ | PUBLISH | Post notification of an event. Used primarily |
+ | | as a method of advertising the existence of an |
+ | | event. |
+ | | |
+ | REQUEST | Make a request for an event. This is an |
+ | | explicit invitation to one or more Attendees. |
+ | | Event requests are also used to update or change |
+ | | an existing event. Clients that cannot handle |
+ | | REQUEST MAY degrade the event to view it as a |
+ | | PUBLISH. |
+ | | |
+ | REPLY | Reply to an event request. Clients may set |
+ | | their status (PARTSTAT) to ACCEPTED, DECLINED, |
+ | | TENTATIVE, or DELEGATED. |
+ | | |
+ | ADD | Add one or more instances to an existing event. |
+ | | |
+ | CANCEL | Cancel one or more instances of an existing |
+ | | event. |
+ | | |
+ | REFRESH | A request is sent to an Organizer by an Attendee |
+ | | asking for the latest version of an event to be |
+ | | resent to the requester. |
+ | | |
+ | COUNTER | Counter a REQUEST with an alternative proposal. |
+ | | Sent by an Attendee to the Organizer. |
+ | | |
+ | DECLINECOUNTER | Decline a counter proposal. Sent to an Attendee |
+ | | by the Organizer. |
+ +----------------+--------------------------------------------------+
+
+3.2.1. PUBLISH
+
+ The "PUBLISH" method in a "VEVENT" calendar component is an
+ unsolicited posting of an iCalendar object. Any CU may add published
+ components to their calendar. The "Organizer" MUST be present in a
+ published iCalendar component. "Attendees" MUST NOT be present. Its
+ expected usage is for encapsulating an arbitrary event as an
+ iCalendar object. The "Organizer" may subsequently update (with
+ another "PUBLISH" method), add instances to (with an "ADD" method),
+ or cancel (with a "CANCEL" method) a previously published "VEVENT"
+ calendar component.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+Daboo Standards Track [Page 18]
+
+RFC 5546 iTIP December 2009
+
+
+ +----------------------------------------------+
+ | Constraints for a METHOD:PUBLISH of a VEVENT |
+ +----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST equal PUBLISH. |
+ | | | |
+ | VEVENT | 1+ | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | SEQUENCE | 0 or 1 | MUST be present if value is |
+ | | | greater than 0; MAY be present if |
+ | | | 0. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0 or 1 | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | TENTATIVE/CONFIRMED/CANCELLED. |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+
+
+
+Daboo Standards Track [Page 19]
+
+RFC 5546 iTIP December 2009
+
+
+ | ATTENDEE | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.2. REQUEST
+
+ The "REQUEST" method in a "VEVENT" component provides the following
+ scheduling functions:
+
+ o Invite "Attendees" to an event.
+
+ o Reschedule an existing event.
+
+ o Response to a "REFRESH" request.
+
+ o Update the details of an existing event, without rescheduling it.
+
+ o Update the status of "Attendees" of an existing event, without
+ rescheduling it.
+
+ o Reconfirm an existing event, without rescheduling it.
+
+ o Forward a "VEVENT" to another uninvited CU.
+
+ o For an existing "VEVENT" calendar component, delegate the role of
+ "Attendee" to another CU.
+
+ o For an existing "VEVENT" calendar component, change the role of
+ "Organizer" to another CU.
+
+ The "Organizer" originates the "REQUEST". The recipients of the
+ "REQUEST" method are the CUs invited to the event, the "Attendees".
+ "Attendees" use the "REPLY" method to convey attendance status to the
+ "Organizer".
+
+
+
+Daboo Standards Track [Page 20]
+
+RFC 5546 iTIP December 2009
+
+
+ The "UID" and "SEQUENCE" properties are used to distinguish the
+ various uses of the "REQUEST" method. If the "UID" property value in
+ the "REQUEST" is not found on the recipient's calendar, then the
+ "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
+ property value is found on the recipient's calendar, then the
+ "REQUEST" is for a rescheduling, an update, or a reconfirmation of
+ the "VEVENT" calendar component.
+
+ For the "REQUEST" method, multiple "VEVENT" components in a single
+ iCalendar object are only permitted for components with the same
+ "UID" property. That is, a series of recurring events may have
+ instance-specific information. In this case, multiple "VEVENT"
+ components are needed to express the entire series.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +----------------------------------------------+
+ | Constraints for a METHOD:REQUEST of a VEVENT |
+ +----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REQUEST. |
+ | | | |
+ | VEVENT | 1+ | All components MUST have the same |
+ | | | UID. |
+ | ATTENDEE | 1+ | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 0 or 1 | MUST be present if value is |
+ | | | greater than 0; MAY be present if |
+ | | | 0. |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+
+
+
+
+
+Daboo Standards Track [Page 21]
+
+RFC 5546 iTIP December 2009
+
+
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | REQUEST-STATUS | 0 | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | TENTATIVE/CONFIRMED. |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.2.1. Rescheduling an Event
+
+ The "REQUEST" method may be used to reschedule an event. A
+ rescheduled event involves a change to the existing event in terms of
+ its time or recurrence intervals and possibly the location or
+ description. If the recipient CUA of a "REQUEST" method finds that
+ the "UID" property value already exists on the calendar but that the
+ "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
+ greater than the value for the existing event, then the "REQUEST"
+ method describes a rescheduling of the event.
+
+
+
+Daboo Standards Track [Page 22]
+
+RFC 5546 iTIP December 2009
+
+
+3.2.2.2. Updating or Reconfirmation of an Event
+
+ The "REQUEST" method may be used to update or reconfirm an event. An
+ update to an existing event does not involve changes to the time or
+ recurrence intervals, and might not involve a change to the location
+ or description for the event. If the recipient CUA of a "REQUEST"
+ method finds that the "UID" property value already exists on the
+ calendar and that the "SEQUENCE" property value in the "REQUEST" is
+ the same as the value for the existing event, then the "REQUEST"
+ method describes an update of the event details, but not a
+ rescheduling of the event.
+
+ The update "REQUEST" method is the appropriate response to a
+ "REFRESH" method sent from an "Attendee" to the "Organizer" of an
+ event.
+
+ The "Organizer" of an event may also send unsolicited "REQUEST"
+ methods. The unsolicited "REQUEST" methods may be used to update the
+ details of the event without rescheduling it, to update the
+ "PARTSTAT" parameter of "Attendees", or to reconfirm the event.
+
+3.2.2.3. Delegating an Event to Another CU
+
+ Some calendar and scheduling systems allow "Attendees" to delegate
+ their presence at an event to another "Calendar User". iTIP supports
+ this concept using the following workflow. Any "Attendee" may
+ delegate their right to participate in a calendar "VEVENT" to another
+ CU. The implication is that the delegate participates in lieu of the
+ original "Attendee", NOT in addition to the "Attendee". The
+ delegator MUST notify the "Organizer" of this action using the steps
+ outlined below. Implementations may support or restrict delegation
+ as they see fit. For instance, some implementations may restrict a
+ delegate from delegating a "REQUEST" to another CU.
+
+ The "Delegator" of an event forwards the existing "REQUEST" to the
+ "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
+ with the calendar address of the "Delegate". The "Delegator" MUST
+ also send a "REPLY" method to the "Organizer" with the "Delegator's"
+ "ATTENDEE" property "PARTSTAT" parameter value set to "DELEGATED".
+ In addition, the "DELEGATED-TO" parameter MUST be included with the
+ calendar address of the "Delegate". Also, a new "ATTENDEE" property
+ for the "Delegate" MUST be included and must specify the calendar
+ user address set in the "DELEGATED-TO" parameter, as above.
+
+ In response to the request, the "Delegate" MUST send a "REPLY" method
+ to the "Organizer", and optionally to the "Delegator". The "REPLY"
+ method SHOULD include the "ATTENDEE" property with the "DELEGATED-
+ FROM" parameter value of the "Delegator's" calendar address.
+
+
+
+Daboo Standards Track [Page 23]
+
+RFC 5546 iTIP December 2009
+
+
+ The "Delegator" may continue to receive updates to the event even
+ though they will not be attending. This is accomplished by the
+ "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in
+ the "REPLY" to the "Organizer".
+
+3.2.2.4. Changing the Organizer
+
+ The situation may arise where the "Organizer" of a "VEVENT" is no
+ longer able to perform the "Organizer" role and abdicates without
+ passing on the "Organizer" role to someone else. When this occurs,
+ the "Attendees" of the "VEVENT" may use out-of-band mechanisms to
+ communicate the situation and agree upon a new "Organizer". The new
+ "Organizer" should then send out a new "REQUEST" with a modified
+ version of the "VEVENT" in which the "SEQUENCE" number has been
+ incremented and the "ORGANIZER" property has been changed to the new
+ "Organizer".
+
+3.2.2.5. Sending on Behalf of the Organizer
+
+ There are a number of scenarios that support the need for a "Calendar
+ User" to act on behalf of the "Organizer" without explicit role
+ changing. This might be the case if the CU designated as "Organizer"
+ is sick or unable to perform duties associated with that function.
+ In these cases, iTIP supports the notion of one CU acting on behalf
+ of another. Using the "SENT-BY" parameter, a "Calendar User" could
+ send an updated "VEVENT" "REQUEST". In the case where one CU sends
+ on behalf of another CU, the "Attendee" responses are still directed
+ back towards the CU designated as "Organizer".
+
+3.2.2.6. Forwarding to an Uninvited CU
+
+ An "Attendee" invited to a "VEVENT" calendar component may send the
+ "VEVENT" calendar component to another new CU not previously
+ associated with the "VEVENT" calendar component. The current
+ "Attendee" invited to the "VEVENT" calendar component does this by
+ forwarding the original "REQUEST" method to the new CU. The new CU
+ can send a "REPLY" to the "Organizer" of the "VEVENT" calendar
+ component. The reply contains an "ATTENDEE" property for the new CU.
+
+ The "Organizer" ultimately decides whether or not the new CU becomes
+ part of the event and is not obligated to do anything with a "REPLY"
+ from a new (uninvited) CU. If the "Organizer" does not want the new
+ CU to be part of the event, the new "ATTENDEE" property is not added
+ to the "VEVENT" calendar component. The "Organizer" MAY send the CU
+ a "CANCEL" message to indicate that they will not be added to the
+ event. If the "Organizer" decides to add the new CU, the new
+ "ATTENDEE" property is added to the "VEVENT" calendar component.
+ Furthermore, the "Organizer" is free to change any "ATTENDEE"
+
+
+
+Daboo Standards Track [Page 24]
+
+RFC 5546 iTIP December 2009
+
+
+ property parameter from the values supplied by the new CU to
+ something the "Organizer" considers appropriate. The "Organizer"
+ SHOULD send the new CU a "REQUEST" message to inform them that they
+ have been added.
+
+ When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
+ MUST NOT make changes to the original message.
+
+3.2.2.7. Updating Attendee Status
+
+ The "Organizer" of an event may also request updated status from one
+ or more "Attendees". The "Organizer" sends a "REQUEST" method to the
+ "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The
+ "SEQUENCE" property for the event is not changed from its previous
+ value. A recipient will determine that the only change in the
+ "REQUEST" is that their "RSVP" property parameter indicates a request
+ for updated status. The recipient SHOULD respond with a "REPLY"
+ method indicating their current status with respect to the "REQUEST".
+
+3.2.3. REPLY
+
+ The "REPLY" method in a "VEVENT" calendar component is used to
+ respond (e.g., accept or decline) to a "REQUEST" or to reply to a
+ delegation "REQUEST". When used to provide a delegation response,
+ the "Delegator" SHOULD include the calendar address of the "Delegate"
+ on the "DELEGATED-TO" property parameter of the "Delegator's"
+ "ATTENDEE" property. The "Delegate" SHOULD include the calendar
+ address of the "Delegator" on the "DELEGATED-FROM" property parameter
+ of the "Delegate's" "ATTENDEE" property.
+
+ The "REPLY" method is also used when processing of a "REQUEST" fails.
+ Depending on the value of the "REQUEST-STATUS" property, no
+ scheduling action may have been performed.
+
+ The "Organizer" of an event may receive the "REPLY" method from a CU
+ not in the original "REQUEST". For example, a "REPLY" may be
+ received from a "Delegate" to an event. In addition, the "REPLY"
+ method may be received from an unknown CU (a "Party Crasher"). This
+ uninvited "Attendee" may be accepted, or the "Organizer" may cancel
+ the event for the uninvited "Attendee" by sending a "CANCEL" method
+ to the uninvited "Attendee".
+
+ An "Attendee" MAY include a message to the "Organizer" using the
+ "COMMENT" property. For example, if the user indicates tentative
+ acceptance and wants to let the "Organizer" know why, the reason can
+ be expressed in the "COMMENT" property value.
+
+
+
+
+
+Daboo Standards Track [Page 25]
+
+RFC 5546 iTIP December 2009
+
+
+ The "Organizer" may also receive a "REPLY" from one CU on behalf of
+ another. Like the scenario enumerated above for the "Organizer",
+ "Attendees" may have another CU respond on their behalf. This is
+ done using the "SENT-BY" parameter.
+
+ The optional properties listed in the table below (those listed as
+ "0+" or "0 or 1") MUST NOT be changed from those of the original
+ request. If property changes are desired, the "COUNTER" message must
+ be used.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +--------------------------------------------+
+ | Constraints for a METHOD:REPLY of a VEVENT |
+ +--------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REPLY. |
+ | | | |
+ | VEVENT | 1+ | All components MUST have the same |
+ | | | UID. |
+ | ATTENDEE | 1 | MUST be the address of the |
+ | | | Attendee replying. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | UID | 1 | MUST be the UID of the original |
+ | | | REQUEST. |
+ | SEQUENCE | 0 or 1 | If non-zero, MUST be the sequence |
+ | | | number of the original REQUEST. |
+ | | | MAY be present if 0. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DTSTART | 0 or 1 | |
+
+
+
+
+Daboo Standards Track [Page 26]
+
+RFC 5546 iTIP December 2009
+
+
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | REQUEST-STATUS | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | |
+ | SUMMARY | 0 or 1 | |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.4. ADD
+
+ The "ADD" method allows the "Organizer" to add one or more new
+ instances to an existing "VEVENT" using a single iTIP message without
+ having to send the entire "VEVENT" with all the existing instance
+ data, as it would have to do if the "REQUEST" method were used.
+
+ The "UID" must be that of the existing event. If the "UID" property
+ value in the "ADD" is not found on the recipient's calendar, then the
+ recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
+ updated with the latest version of the "VEVENT". If an "Attendee"
+ implementation does not support the "ADD" method, it should respond
+ with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
+
+
+
+
+Daboo Standards Track [Page 27]
+
+RFC 5546 iTIP December 2009
+
+
+ When handling an "ADD" message, the "Attendee" treats each component
+ in the "ADD" message as if it were referenced via an "RDATE" in the
+ main component.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +------------------------------------------+
+ | Constraints for a METHOD:ADD of a VEVENT |
+ +------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be ADD. |
+ | | | |
+ | VEVENT | 1 | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | MUST be greater than 0. |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | MUST match that of the original |
+ | | | event. |
+ | ATTACH | 0+ | |
+ | ATTENDEE | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | TENTATIVE/CONFIRMED. |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+
+
+
+Daboo Standards Track [Page 28]
+
+RFC 5546 iTIP December 2009
+
+
+ | EXDATE | 0 | |
+ | RECURRENCE-ID | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | RDATE | 0 | |
+ | RRULE | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.5. CANCEL
+
+ The "CANCEL" method in a "VEVENT" calendar component is used to send
+ a cancellation notice of an existing event request to the affected
+ "Attendees". The message is sent by the "Organizer" of the event.
+ For a recurring event, either the whole event or instances of an
+ event may be cancelled. To cancel the complete range of a recurring
+ event, the "UID" property value for the event MUST be specified and a
+ "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In
+ order to cancel an individual instance of the event, the
+ "RECURRENCE-ID" property value for the event MUST be specified in the
+ "CANCEL" method.
+
+ There are two options for canceling a sequence of instances of a
+ recurring "VEVENT" calendar component:
+
+ a. The "RECURRENCE-ID" property for an instance in the sequence MUST
+ be specified with the "RANGE" property parameter value of
+ "THISANDFUTURE" to indicate cancellation of the specified
+ "VEVENT" calendar component and all instances after.
+
+ b. Individual recurrence instances may be cancelled by specifying
+ multiple "VEVENT" components each with a "RECURRENCE-ID" property
+ corresponding to one of the instances to be cancelled.
+
+
+
+
+
+
+Daboo Standards Track [Page 29]
+
+RFC 5546 iTIP December 2009
+
+
+ The "Organizer" MUST send a "CANCEL" message to each "Attendee"
+ affected by the cancellation. This can be done using a single
+ "CANCEL" message for all "Attendees" or by using multiple messages
+ with different subsets of the affected "Attendees" in each.
+
+ When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
+ incremented as described in Section 2.1.4.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +---------------------------------------------+
+ | Constraints for a METHOD:CANCEL of a VEVENT |
+ +---------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be CANCEL. |
+ | | | |
+ | VEVENT | 1+ | All must have the same UID. |
+ | ATTENDEE | 0+ | MUST include some or all |
+ | | | Attendees being removed from the |
+ | | | event. MUST include some or all |
+ | | | Attendees if the entire event is |
+ | | | cancelled. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | |
+ | UID | 1 | MUST be the UID of the original |
+ | | | REQUEST. |
+ | COMMENT | 0+ | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DTSTART | 0 or 1 | |
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+
+
+
+Daboo Standards Track [Page 30]
+
+RFC 5546 iTIP December 2009
+
+
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MUST be set to CANCELLED to |
+ | | | cancel the entire event. If |
+ | | | uninviting specific Attendees, |
+ | | | then MUST NOT be included. |
+ | SUMMARY | 0 or 1 | |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.6. REFRESH
+
+ The "REFRESH" method in a "VEVENT" calendar component is used by
+ "Attendees" of an existing event to request an updated description
+ from the event "Organizer". The "REFRESH" method must specify the
+ "UID" property of the event to update. A recurrence instance of an
+ event may be requested by specifying the "RECURRENCE-ID" property
+ corresponding to the associated event. The "Organizer" responds with
+ the latest description and version of the event.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+Daboo Standards Track [Page 31]
+
+RFC 5546 iTIP December 2009
+
+
+ +----------------------------------------------+
+ | Constraints for a METHOD:REFRESH of a VEVENT |
+ +----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REFRESH. |
+ | | | |
+ | VEVENT | 1 | |
+ | ATTENDEE | 1 | MUST be the address of requester. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | UID | 1 | MUST be the UID associated with |
+ | | | original REQUEST. |
+ | COMMENT | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | ATTACH | 0 | |
+ | CATEGORIES | 0 | |
+ | CLASS | 0 | |
+ | CONTACT | 0 | |
+ | CREATED | 0 | |
+ | DESCRIPTION | 0 | |
+ | DTEND | 0 | |
+ | DTSTART | 0 | |
+ | DURATION | 0 | |
+ | EXDATE | 0 | |
+ | GEO | 0 | |
+ | LAST-MODIFIED | 0 | |
+ | LOCATION | 0 | |
+ | PRIORITY | 0 | |
+ | RDATE | 0 | |
+ | RELATED-TO | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | RESOURCES | 0 | |
+ | RRULE | 0 | |
+ | SEQUENCE | 0 | |
+ | STATUS | 0 | |
+ | SUMMARY | 0 | |
+ | TRANSP | 0 | |
+ | URL | 0 | |
+ | | | |
+
+
+
+
+Daboo Standards Track [Page 32]
+
+RFC 5546 iTIP December 2009
+
+
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.7. COUNTER
+
+ The "COUNTER" method for a "VEVENT" calendar component is used by an
+ "Attendee" of an existing event to submit to the "Organizer" a
+ counter proposal to the event. The "Attendee" sends this message to
+ the "Organizer" of the event.
+
+ The counter proposal is an iCalendar object consisting of a "VEVENT"
+ calendar component that provides the complete description of the
+ alternate event.
+
+ The "Organizer" rejects the counter proposal by sending the
+ "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
+ counter proposal by rescheduling the event as described in
+ Section 3.2.2.1, "Rescheduling an Event". The "Organizer's" CUA
+ SHOULD send a "REQUEST" message to all "Attendees" affected by any
+ change triggered by an accepted "COUNTER".
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +----------------------------------------------+
+ | Constraints for a METHOD:COUNTER of a VEVENT |
+ +----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be COUNTER. |
+ | | | |
+ | VEVENT | 1 | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+
+
+
+
+Daboo Standards Track [Page 33]
+
+RFC 5546 iTIP December 2009
+
+
+ | ORGANIZER | 1 | MUST be the Organizer of the |
+ | | | original event. |
+ | SEQUENCE | 1 | MUST echo the original SEQUENCE |
+ | | | number. MUST be present if |
+ | | | non-zero. MAY be present if |
+ | | | zero. |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | MUST be the UID associated with |
+ | | | the REQUEST being countered. |
+ | ATTACH | 0+ | |
+ | ATTENDEE | 0+ | Can also be used to propose other |
+ | | | Attendees. |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | REQUEST-STATUS | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | Value must be one of |
+ | | | CONFIRMED/TENATIVE/CANCELLED. |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+
+
+
+Daboo Standards Track [Page 34]
+
+RFC 5546 iTIP December 2009
+
+
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.2.8. DECLINECOUNTER
+
+ The "DECLINECOUNTER" method in a "VEVENT" calendar component is used
+ by the "Organizer" of an event to reject a counter proposal submitted
+ by an "Attendee". The "Organizer" must send the "DECLINECOUNTER"
+ message to the "Attendee" that sent the "COUNTER" method to the
+ "Organizer".
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +-----------------------------------------------------+
+ | Constraints for a METHOD:DECLINECOUNTER of a VEVENT |
+ +-----------------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be DECLINECOUNTER. |
+ | | | |
+ | VEVENT | 1+ | All components MUST have the same |
+ | | | UID. |
+ | ATTENDEE | 1+ | MUST for all Attendees. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | MUST echo the original SEQUENCE |
+ | | | number. |
+ | UID | 1 | MUST echo original UID. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTSTART | 0 or 1 | |
+ | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+
+
+
+Daboo Standards Track [Page 35]
+
+RFC 5546 iTIP December 2009
+
+
+ | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | REQUEST-STATUS | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | TENTATIVE/CONFIRMED. |
+ | SUMMARY | 0 or 1 | Can be null. |
+ | TRANSP | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VALARM | 0 | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 36]
+
+RFC 5546 iTIP December 2009
+
+
+3.3. Methods for VFREEBUSY Components
+
+ This section defines the property set for the methods that are
+ applicable to the "VFREEBUSY" calendar component. Each of the
+ methods is defined using a restriction table.
+
+ This document only addresses the transfer of busy time information.
+ Applications desiring free time information MUST infer this from
+ available busy time information.
+
+ The "FREEBUSY" property value MAY include a list of values, separated
+ by the COMMA character (US-ASCII decimal 44). Alternately, multiple
+ busy time periods MAY be specified with multiple instances of the
+ "FREEBUSY" property. Both forms MUST be supported by implementations
+ conforming to this document. Duplicate busy time periods SHOULD NOT
+ be specified in an iCalendar object. However, two different busy
+ time periods MAY overlap.
+
+ "FREEBUSY" properties SHOULD be sorted such that their values are in
+ ascending order, based on the start time and then the end time, with
+ the earliest periods first. For example, today's busy time
+ information should appear after yesterday's busy time information.
+ And the busy time for this half-hour should appear after the busy
+ time for earlier today. Busy time periods can also span a day
+ boundary.
+
+ The following summarizes the methods that are defined for the
+ "VFREEBUSY" calendar component.
+
+ +---------+-------------------------------------+
+ | Method | Description |
+ +---------+-------------------------------------+
+ | PUBLISH | Publish unsolicited busy time data. |
+ | | |
+ | REQUEST | Request busy time data. |
+ | | |
+ | REPLY | Reply to a busy time request. |
+ +---------+-------------------------------------+
+
+3.3.1. PUBLISH
+
+ The "PUBLISH" method in a "VFREEBUSY" calendar component is used to
+ publish busy time data. The method may be sent from one CU to any
+ other. The purpose of the method is to provide a way to send
+ unsolicited busy time data. That is, the busy time data is not being
+ sent as a "REPLY" to the receipt of a "REQUEST" method.
+
+
+
+
+
+Daboo Standards Track [Page 37]
+
+RFC 5546 iTIP December 2009
+
+
+ The "ORGANIZER" property MUST be specified in the busy time
+ information. The value is the CU address of the originator of the
+ busy time information.
+
+ The busy time information within the iCalendar object MAY be grouped
+ into more than one "VFREEBUSY" calendar component. This capability
+ allows busy time periods to be grouped according to some common
+ periodicity, such as a calendar week, month, or year. In this case,
+ each "VFREEBUSY" calendar component MUST include the "ORGANIZER",
+ "DTSTART", and "DTEND" properties in order to specify the source of
+ the busy time information and the date and time interval over which
+ the busy time information covers.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 38]
+
+RFC 5546 iTIP December 2009
+
+
+ +-------------------------------------------------+
+ | Constraints for a METHOD:PUBLISH of a VFREEBUSY |
+ +-------------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be PUBLISH. |
+ | | | |
+ | VFREEBUSY | 1+ | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | DateTime values must be in UTC. |
+ | DTEND | 1 | DateTime values must be in UTC. |
+ | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
+ | | | instances are allowed. Multiple |
+ | | | instances SHOULD be sorted in |
+ | | | ascending order. |
+ | ORGANIZER | 1 | MUST contain the address of |
+ | | | originator of busy time data. |
+ | UID | 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | URL | 0 or 1 | Specifies busy time URL. |
+ | ATTENDEE | 0 | |
+ | DURATION | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTIMEZONE | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 39]
+
+RFC 5546 iTIP December 2009
+
+
+3.3.2. REQUEST
+
+ The "REQUEST" method in a "VFREEBUSY" calendar component is used to
+ ask a "Calendar User" for their busy time information. The request
+ may be for a busy time information bounded by a specific date and
+ time interval.
+
+ This message only permits requests for busy time information. The
+ message is sent from a "Calendar User" requesting the busy time
+ information of one or more intended recipients.
+
+ If the originator of the "REQUEST" method is not authorized to make a
+ busy time request on the recipient's calendar system, then an
+ exception message SHOULD be returned in a "REPLY" method, but no busy
+ time data need be returned.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 40]
+
+RFC 5546 iTIP December 2009
+
+
+ +-------------------------------------------------+
+ | Constraints for a METHOD:REQUEST of a VFREEBUSY |
+ +-------------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REQUEST. |
+ | | | |
+ | VFREEBUSY | 1 | |
+ | ATTENDEE | 1+ | Contains the calendar user |
+ | | | addresses of the "Calendar Users" |
+ | | | whose freebusy is being |
+ | | | requested. |
+ | DTEND | 1 | DateTime values must be in UTC. |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | DateTime values must be in UTC. |
+ | ORGANIZER | 1 | MUST be the request originator's |
+ | | | address. |
+ | UID | 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | FREEBUSY | 0 | |
+ | DURATION | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | URL | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTIMEZONE | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 41]
+
+RFC 5546 iTIP December 2009
+
+
+3.3.3. REPLY
+
+ The "REPLY" method in a "VFREEBUSY" calendar component is used to
+ respond to a busy time request. The method is sent by the recipient
+ of a busy time request to the originator of the request.
+
+ The "REPLY" method may also be used to respond to an unsuccessful
+ "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy
+ time information may be returned.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 42]
+
+RFC 5546 iTIP December 2009
+
+
+ +-----------------------------------------------+
+ | Constraints for a METHOD:REPLY of a VFREEBUSY |
+ +-----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REPLY. |
+ | | | |
+ | VFREEBUSY | 1 | |
+ | ATTENDEE | 1 | MUST be the address of the |
+ | | | Attendee replying. |
+ | DTSTAMP | 1 | |
+ | DTEND | 1 | DateTime values must be in UTC. |
+ | DTSTART | 1 | DateTime values must be in UTC. |
+ | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
+ | | | instances are allowed. Multiple |
+ | | | instances SHOULD be sorted in |
+ | | | ascending order. |
+ | ORGANIZER | 1 | MUST be the request originator's |
+ | | | address. |
+ | UID | 1 | MUST be the UID of the original |
+ | | | REQUEST. |
+ | COMMENT | 0+ | |
+ | CONTACT | 0 or 1 | |
+ | REQUEST-STATUS | 0+ | |
+ | URL | 0 or 1 | Specifies busy time URL. |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | DURATION | 0 | |
+ | SEQUENCE | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VTIMEZONE | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+
+
+
+Daboo Standards Track [Page 43]
+
+RFC 5546 iTIP December 2009
+
+
+3.4. Methods for VTODO Components
+
+ This section defines the property set for the methods that are
+ applicable to the "VTODO" calendar component. Each of the methods is
+ defined using a restriction table that specifies the property
+ constraints that define the particular method.
+
+ The following summarizes the methods that are defined for the "VTODO"
+ calendar component.
+
+ +----------------+--------------------------------------------------+
+ | Method | Description |
+ +----------------+--------------------------------------------------+
+ | PUBLISH | Post notification of a VTODO. Used primarily as |
+ | | a method of advertising the existence of a |
+ | | VTODO. |
+ | | |
+ | REQUEST | Assign a VTODO. This is an explicit assignment |
+ | | to one or more Calendar Users. The REQUEST |
+ | | method is also used to update or change an |
+ | | existing VTODO. Clients that cannot handle |
+ | | REQUEST MAY degrade the method to treat it as a |
+ | | PUBLISH. |
+ | | |
+ | REPLY | Reply to a VTODO request. Attendees MAY set |
+ | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, |
+ | | DELEGATED, PARTIAL, and COMPLETED. |
+ | | |
+ | ADD | Add one or more instances to an existing to-do. |
+ | | |
+ | CANCEL | Cancel one or more instances of an existing |
+ | | to-do. |
+ | | |
+ | REFRESH | A request sent to a VTODO Organizer asking for |
+ | | the latest version of a VTODO. |
+ | | |
+ | COUNTER | Counter a REQUEST with an alternative proposal. |
+ | | |
+ | DECLINECOUNTER | Decline a counter proposal by an Attendee. |
+ +----------------+--------------------------------------------------+
+
+3.4.1. PUBLISH
+
+ The "PUBLISH" method in a "VTODO" calendar component has no
+ associated response. It is simply a posting of an iCalendar object
+ that may be added to a calendar. It MUST have an "Organizer". It
+ MUST NOT have "Attendees". Its expected usage is for encapsulating
+ an arbitrary "VTODO" calendar component as an iCalendar object. The
+
+
+
+Daboo Standards Track [Page 44]
+
+RFC 5546 iTIP December 2009
+
+
+ "Organizer" MAY subsequently update (with another "PUBLISH" method),
+ add instances to (with an "ADD" method), or cancel (with a "CANCEL"
+ method) a previously published "VTODO" calendar component.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +---------------------------------------------+
+ | Constraints for a METHOD:PUBLISH of a VTODO |
+ +---------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be PUBLISH. |
+ | | | |
+ | VTODO | 1+ | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | PRIORITY | 1 | |
+ | SEQUENCE | 0 or 1 | MUST be present if value is |
+ | | | greater than 0; MAY be present if |
+ | | | 0. |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+
+
+
+Daboo Standards Track [Page 45]
+
+RFC 5546 iTIP December 2009
+
+
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | COMPLETED/NEEDS-ACTION/ |
+ | | | IN-PROCESS/CANCELLED. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | ATTENDEE | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.2. REQUEST
+
+ The "REQUEST" method in a "VTODO" calendar component provides the
+ following scheduling functions:
+
+ o Assign a to-do to one or more "Calendar Users".
+
+ o Reschedule an existing to-do.
+
+ o Update the details of an existing to-do, without rescheduling it.
+
+ o Update the completion status of "Attendees" of an existing to-do,
+ without rescheduling it.
+
+ o Reconfirm an existing to-do, without rescheduling it.
+
+ o Delegate/reassign an existing to-do to another "Calendar User".
+
+ The assigned "Calendar Users" are identified in the "VTODO" calendar
+ component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property
+ value sequences.
+
+
+
+Daboo Standards Track [Page 46]
+
+RFC 5546 iTIP December 2009
+
+
+ Typically, the originator of a "REQUEST" is the "Organizer" of the
+ to-do, and the recipient of a "REQUEST" is the "Calendar User"
+ assigned the to-do. The "Attendee" uses the "REPLY" method to convey
+ their acceptance and completion status to the "Organizer" of the
+ "REQUEST".
+
+ The "UID", "SEQUENCE", and "DTSTAMP" properties are used to
+ distinguish the various uses of the "REQUEST" method. If the "UID"
+ property value in the "REQUEST" is not found on the recipient's
+ calendar, then the "REQUEST" is for a new to-do. If the "UID"
+ property value is found on the recipient's calendar, then the
+ "REQUEST" is a rescheduling, an update, or a reconfirmation of the
+ "VTODO" calendar object.
+
+ If the "Organizer" of the "REQUEST" method is not authorized to make
+ a to-do request on the "Attendee's" calendar system, then an
+ exception is returned in the "REQUEST-STATUS" property of a
+ subsequent "REPLY" method, but no scheduling action is performed.
+
+ For the "REQUEST" method, multiple "VTODO" components in a single
+ iCalendar object are only permitted for components with the same
+ "UID" property. That is, a series of recurring events may have
+ instance-specific information. In this case, multiple "VTODO"
+ components are needed to express the entire series.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +---------------------------------------------+
+ | Constraints for a METHOD:REQUEST of a VTODO |
+ +---------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REQUEST. |
+ | | | |
+ | VTODO | 1+ | All components must have the same |
+ | | | UID. |
+ | ATTENDEE | 1+ | |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | PRIORITY | 1 | |
+ | SEQUENCE | 0 or 1 | MUST be present if value is |
+ | | | greater than 0; MAY be present if |
+ | | | 0. |
+ | SUMMARY | 1 | Can be null. |
+
+
+
+Daboo Standards Track [Page 47]
+
+RFC 5546 iTIP December 2009
+
+
+ | UID | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | COMPLETED/NEEDS-ACTION/ |
+ | | | IN-PROCESS. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+
+
+Daboo Standards Track [Page 48]
+
+RFC 5546 iTIP December 2009
+
+
+3.4.2.1. REQUEST for Rescheduling a VTODO
+
+ The "REQUEST" method may be used to reschedule a "VTODO" calendar
+ component.
+
+ Rescheduling a "VTODO" calendar component involves a change to the
+ existing "VTODO" calendar component in terms of its start or due
+ time, recurrence intervals, and possibly the description. If the
+ recipient CUA of a "REQUEST" method finds that the "UID" property
+ value already exists on the calendar but that the "SEQUENCE" property
+ value in the "REQUEST" is greater than the value for the existing
+ "VTODO", then the "REQUEST" method describes a rescheduling of the
+ "VTODO" calendar component.
+
+3.4.2.2. REQUEST for Update or Reconfirmation of a VTODO
+
+ The "REQUEST" method may be used to update or reconfirm a "VTODO"
+ calendar component. Reconfirmation is merely an update of "Attendee"
+ completion status or overall "VTODO" calendar component status.
+
+ An update to an existing "VTODO" calendar component does not involve
+ changes to the start or due time, recurrence intervals, or
+ (generally) the description for the "VTODO" calendar component. If
+ the recipient CUA of a "REQUEST" method finds that the "UID" property
+ value already exists on the calendar and that the "SEQUENCE" property
+ value in the "REQUEST" is the same as the value for the existing
+ event, then the "REQUEST" method describes an update of the "VTODO"
+ calendar component details, but not a rescheduling of the "VTODO"
+ calendar component.
+
+ The update "REQUEST" is the appropriate response to a "REFRESH"
+ method sent from an "Attendee" to the "Organizer" of a "VTODO"
+ calendar component.
+
+ Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a
+ "VTODO" calendar component. The unsolicited "REQUEST" methods are
+ used to update the details of the "VTODO" (without rescheduling it or
+ updating the completion status of "Attendees") or the "VTODO"
+ calendar component itself (i.e., reconfirm the "VTODO").
+
+3.4.2.3. REQUEST for Delegating a VTODO
+
+ The "REQUEST" method is also used to delegate or reassign ownership
+ of a "VTODO" calendar component to another "Calendar User". For
+ example, it may be used to delegate an "Attendee's" role (i.e.,
+ "chair" or "participant") for a "VTODO" calendar component. The
+ "REQUEST" method is sent by one of the "Attendees" of an existing
+ "VTODO" calendar component to some other individual.
+
+
+
+Daboo Standards Track [Page 49]
+
+RFC 5546 iTIP December 2009
+
+
+ For the purposes of this description, the "Attendee" delegating the
+ "VTODO" calendar component is referred to as the "Delegator". The
+ "Attendee" receiving the delegation request is referred to as the
+ "Delegate".
+
+ The "Delegator" of a "VTODO" calendar component MUST forward the
+ existing "REQUEST" method for a "VTODO" calendar component to the
+ "Delegate". The "VTODO" calendar component description MUST include
+ the "Delegator's" up-to-date "VTODO" calendar component definition.
+ The "REQUEST" method MUST also include an "ATTENDEE" property with
+ the calendar address of the "Delegate". The "Delegator" MUST also
+ send a "REPLY" method back to the "Organizer" with the "Delegator's"
+ "Attendee" property "PARTSTAT" parameter value set to "DELEGATED".
+ In addition, the "DELEGATED-TO" parameter MUST be included with the
+ calendar address of the "Delegate". A response to the delegation
+ "REQUEST" is sent from the "Delegate" to the "Organizer", and
+ optionally to the "Delegator". The "REPLY" method from the
+ "Delegate" SHOULD include the "ATTENDEE" property with their calendar
+ address and the "DELEGATED-FROM" parameter with the value of the
+ "Delegator's" calendar address.
+
+ The delegation "REQUEST" method MUST assign a value for the "RSVP"
+ property parameter associated with the "Delegator's" "Attendee"
+ property to that of the "Delegate's" "ATTENDEE" property. For
+ example, if the "Delegator's" "ATTENDEE" property specifies
+ "RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify
+ "RSVP=TRUE".
+
+3.4.2.4. REQUEST Forwarded to an Uninvited Calendar User
+
+ An "Attendee" assigned a "VTODO" calendar component may send the
+ "VTODO" calendar component to another new CU not previously
+ associated with the "VTODO" calendar component. The current
+ "Attendee" assigned the "VTODO" calendar component does this by
+ forwarding the original "REQUEST" method to the new CU. The new CU
+ can send a "REPLY" to the "Organizer" of the "VTODO" calendar
+ component. The reply contains an "ATTENDEE" property for the new CU.
+
+ The "Organizer" ultimately decides whether or not the new CU becomes
+ part of the to-do and is not obligated to do anything with a "REPLY"
+ from a new (uninvited) CU. If the "Organizer" does not want the new
+ CU to be part of the to-do, the new "ATTENDEE" property is not added
+ to the "VTODO" calendar component. The "Organizer" MAY send the CU a
+ "CANCEL" message to indicate that they will not be added to the to-
+ do. If the "Organizer" decides to add the new CU, the new "ATTENDEE"
+ property is added to the "VTODO" calendar component. Furthermore,
+ the "Organizer" is free to change any "ATTENDEE" property parameter
+ from the values supplied by the new CU to something the "Organizer"
+
+
+
+Daboo Standards Track [Page 50]
+
+RFC 5546 iTIP December 2009
+
+
+ considers appropriate. The "Organizer" SHOULD send the new
+ "Attendee" a "REQUEST" message to inform them that they have been
+ added.
+
+ When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
+ MUST NOT make changes to the original message.
+
+3.4.2.5. REQUEST Updated Attendee Status
+
+ An "Organizer" of a "VTODO" may request an updated status from one or
+ more "Attendees". The "Organizer" sends a "REQUEST" method to the
+ "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The
+ "SEQUENCE" property for the "VTODO" is not changed from its previous
+ value. A recipient determines that the only change in the "REQUEST"
+ is that their "RSVP" property parameter indicates a request for an
+ updated status. The recipient SHOULD respond with a "REPLY" method
+ indicating their current status with respect to the "REQUEST".
+
+3.4.3. REPLY
+
+ The "REPLY" method in a "VTODO" calendar component is used to respond
+ (e.g., accept or decline) to a request or to reply to a delegation
+ request. It is also used by an "Attendee" to update their completion
+ status. When used to provide a delegation response, the "Delegator"
+ MUST include the calendar address of the "Delegate" in the
+ "DELEGATED-TO" parameter of the "Delegator's" "ATTENDEE" property.
+ The "Delegate" MUST include the calendar address of the "Delegator"
+ on the "DELEGATED-FROM" parameter of the "Delegate's" "ATTENDEE"
+ property.
+
+ The "REPLY" method MAY also be used to respond to an unsuccessful
+ "VTODO" calendar component "REQUEST" method. Depending on the
+ "REQUEST-STATUS" value, no scheduling action may have been performed.
+
+ The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY"
+ method from a "Calendar User" not in the original "REQUEST". For
+ example, a "REPLY" method MAY be received from a "Delegate" of a
+ "VTODO" calendar component. In addition, the "REPLY" method MAY be
+ received from an unknown "Calendar User" who has been forwarded the
+ "REQUEST" by an original "Attendee" of the "VTODO" calendar
+ component. This uninvited "Attendee" MAY be accepted or the
+ "Organizer" MAY cancel the "VTODO" calendar component for the
+ uninvited "Attendee" by sending them a "CANCEL" method.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+Daboo Standards Track [Page 51]
+
+RFC 5546 iTIP December 2009
+
+
+ +-------------------------------------------+
+ | Constraints for a METHOD:REPLY of a VTODO |
+ +-------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REPLY. |
+ | | | |
+ | VTODO | 1+ | All components MUST have the same |
+ | | | UID. |
+ | ATTENDEE | 1 | MUST be the address of the |
+ | | | Attendee replying. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | REQUEST-STATUS | 0+ | |
+ | UID | 1 | MUST be the UID of the original |
+ | | | REQUEST. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTSTART | 0 or 1 | |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | SEQUENCE | 0 or 1 | MUST be the sequence number of |
+ | | | the original REQUEST if greater |
+ | | | than 0. MAY be present if 0. |
+
+
+
+Daboo Standards Track [Page 52]
+
+RFC 5546 iTIP December 2009
+
+
+ | STATUS | 0 or 1 | |
+ | SUMMARY | 0 or 1 | Can be null. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.4. ADD
+
+ The "ADD" method allows the "Organizer" to add one or more new
+ instances to an existing "VTODO" using a single iTIP message without
+ having to send the entire "VTODO" with all the existing instance
+ data, as it would have to do if the "REQUEST" method were used.
+
+ The "UID" must be that of the existing to-do. If the "UID" property
+ value in the "ADD" is not found on the recipient's calendar, then the
+ recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
+ updated with the latest version of the "VTODO". If an "Attendee"
+ implementation does not support the "ADD" method, it should respond
+ with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
+
+ When handling an "ADD" message, the "Attendee" treats each component
+ in the "ADD" message as if it were referenced via an "RDATE" in the
+ main component.
+
+ The "SEQUENCE" property value is incremented since the sequence of
+ to-dos has changed.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 53]
+
+RFC 5546 iTIP December 2009
+
+
+ +-----------------------------------------+
+ | Constraints for a METHOD:ADD of a VTODO |
+ +-----------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be ADD. |
+ | | | |
+ | VTODO | 1 | |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | PRIORITY | 1 | |
+ | SEQUENCE | 1 | MUST be greater than 0. |
+ | SUMMARY | 1 | Can be null. |
+ | UID | 1 | MUST match that of the original |
+ | | | to-do. |
+ | ATTACH | 0+ | |
+ | ATTENDEE | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTSTART | 0 or 1 | |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | COMPLETED/NEEDS-ACTION/ |
+ | | | IN-PROCESS. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | EXDATE | 0 | |
+ | RECURRENCE-ID | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | RDATE | 0 | |
+ | RRULE | 0 | |
+
+
+
+Daboo Standards Track [Page 54]
+
+RFC 5546 iTIP December 2009
+
+
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VJOURNAL | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.5. CANCEL
+
+ The "CANCEL" method in a "VTODO" calendar component is used to send a
+ cancellation notice of an existing "VTODO" calendar request to the
+ affected "Attendees". The message is sent by the "Organizer" of a
+ "VTODO" calendar component to the "Attendees" of the "VTODO" calendar
+ component. For a recurring "VTODO" calendar component, either the
+ whole "VTODO" calendar component or instances of a "VTODO" calendar
+ component may be cancelled. To cancel the complete range of a
+ recurring "VTODO" calendar component, the "UID" property value for
+ the "VTODO" calendar component MUST be specified and a "RECURRENCE-
+ ID" MUST NOT be specified in the "CANCEL" method. In order to cancel
+ an individual instance of a recurring "VTODO" calendar component, the
+ "RECURRENCE-ID" property value for the "VTODO" calendar component
+ MUST be specified in the "CANCEL" method.
+
+ There are two options for canceling a sequence of instances of a
+ recurring "VTODO" calendar component:
+
+ a. The "RECURRENCE-ID" property for an instance in the sequence MUST
+ be specified with the "RANGE" property parameter value of
+ "THISANDFUTURE" to indicate cancellation of the specified "VTODO"
+ calendar component and all instances after.
+
+ b. Individual recurrence instances may be cancelled by specifying
+ multiple "VTODO" components each with a "RECURRENCE-ID" property
+ corresponding to one of the instances to be cancelled.
+
+ The "Organizer" MUST send a "CANCEL" message to each "Attendee"
+ affected by the cancellation. This can be done by using either a
+ single "CANCEL" message for all "Attendees" or multiple messages with
+ different subsets of the affected "Attendees" in each.
+
+
+
+Daboo Standards Track [Page 55]
+
+RFC 5546 iTIP December 2009
+
+
+ When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
+ incremented as described in Section 2.1.4.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +--------------------------------------------+
+ | Constraints for a METHOD:CANCEL of a VTODO |
+ +--------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be CANCEL. |
+ | | | |
+ | VTODO | 1+ | |
+ | ATTENDEE | 0+ | MUST include some or all |
+ | | | Attendees being removed from the |
+ | | | to-do. MUST include some or all |
+ | | | Attendees if the entire to-do is |
+ | | | cancelled. |
+ | UID | 1 | MUST echo original UID. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTSTART | 0 or 1 | |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | RDATE | 0+ | |
+
+
+
+
+
+
+
+Daboo Standards Track [Page 56]
+
+RFC 5546 iTIP December 2009
+
+
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | STATUS | 0 or 1 | MUST be set to CANCELLED to |
+ | | | cancel the entire VTODO. If |
+ | | | removing specific Attendees, then |
+ | | | MUST NOT be included. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.6. REFRESH
+
+ The "REFRESH" method in a "VTODO" calendar component is used by
+ "Attendees" of an existing "VTODO" calendar component to request an
+ updated description from the "Organizer" of the "VTODO" calendar
+ component. The "Organizer" of the "VTODO" calendar component MAY use
+ this method to request an updated status from the "Attendees". The
+ "REFRESH" method MUST specify the "UID" property corresponding to the
+ "VTODO" calendar component needing update.
+
+ A refresh of a recurrence instance of a "VTODO" calendar component
+ may be requested by specifying the "RECURRENCE-ID" property
+ corresponding to the associated "VTODO" calendar component. The
+ "Organizer" responds with the latest description and rendition of the
+ "VTODO" calendar component. In most cases, this will be a "REQUEST"
+ unless the "VTODO" has been cancelled, in which case the "Organizer"
+ MUST send a "CANCEL". This method is intended to facilitate machine
+ processing of requests for updates to a "VTODO" calendar component.
+
+
+
+Daboo Standards Track [Page 57]
+
+RFC 5546 iTIP December 2009
+
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +---------------------------------------------+
+ | Constraints for a METHOD:REFRESH of a VTODO |
+ +---------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be REFRESH. |
+ | | | |
+ | VTODO | 1 | |
+ | ATTENDEE | 1 | |
+ | DTSTAMP | 1 | |
+ | UID | 1 | MUST echo original UID. |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | ATTACH | 0 | |
+ | CATEGORIES | 0 | |
+ | CLASS | 0 | |
+ | COMMENT | 0 | |
+ | COMPLETED | 0 | |
+ | CONTACT | 0 | |
+ | CREATED | 0 | |
+ | DESCRIPTION | 0 | |
+ | DTSTART | 0 | |
+ | DUE | 0 | |
+ | DURATION | 0 | |
+ | EXDATE | 0 | |
+ | GEO | 0 | |
+ | LAST-MODIFIED | 0 | |
+ | LOCATION | 0 | |
+ | ORGANIZER | 0 | |
+ | PERCENT-COMPLETE | 0 | |
+ | PRIORITY | 0 | |
+ | RDATE | 0 | |
+ | RELATED-TO | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | RESOURCES | 0 | |
+ | RRULE | 0 | |
+ | SEQUENCE | 0 | |
+ | STATUS | 0 | |
+ | URL | 0 | |
+
+
+
+Daboo Standards Track [Page 58]
+
+RFC 5546 iTIP December 2009
+
+
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.7. COUNTER
+
+ The "COUNTER" method in a "VTODO" calendar component is used by an
+ "Attendee" of an existing "VTODO" calendar component to submit to the
+ "Organizer" a counter proposal for the "VTODO" calendar component.
+
+ The counter proposal is an iCalendar object consisting of a "VTODO"
+ calendar component that provides the complete description of the
+ alternate "VTODO" calendar component.
+
+ The "Organizer" rejects the counter proposal by sending the
+ "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
+ counter proposal by rescheduling the to-do as described in
+ Section 3.4.2.1, "REQUEST for Rescheduling a To-Do". The
+ "Organizer's" CUA SHOULD send a "REQUEST" message to all "Attendees"
+ affected by any change triggered by an accepted "COUNTER".
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +---------------------------------------------+
+ | Constraints for a METHOD:COUNTER of a VTODO |
+ +---------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be COUNTER. |
+ | | | |
+ | VTODO | 1 | |
+ | ATTENDEE | 1+ | |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | PRIORITY | 1 | |
+ | SUMMARY | 1 | Can be null. |
+
+
+
+Daboo Standards Track [Page 59]
+
+RFC 5546 iTIP December 2009
+
+
+ | UID | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | Can be null. |
+ | DTSTART | 0 or 1 | |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | REQUEST-STATUS | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE |
+ | | | number. MUST be present if |
+ | | | non-zero. MAY be present if |
+ | | | zero. |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | COMPLETED/NEEDS-ACTION/ |
+ | | | IN-PROCESS/CANCELLED. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+
+
+
+
+Daboo Standards Track [Page 60]
+
+RFC 5546 iTIP December 2009
+
+
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.4.8. DECLINECOUNTER
+
+ The "DECLINECOUNTER" method in a "VTODO" calendar component is used
+ by an "Organizer" of the "VTODO" calendar component to reject a
+ counter proposal offered by one of the "Attendees". The "Organizer"
+ sends the message to the "Attendee" that sent the "COUNTER" method to
+ the "Organizer".
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +----------------------------------------------------+
+ | Constraints for a METHOD:DECLINECOUNTER of a VTODO |
+ +----------------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be DECLINECOUNTER. |
+ | | | |
+ | VTODO | 1 | |
+ | ATTENDEE | 1+ | MUST for all ATTENDEEs. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | MUST echo the original SEQUENCE |
+ | | | number. |
+ | UID | 1 | MUST echo original UID. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | COMPLETED | 0 or 1 | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTSTART | 0 or 1 | |
+ | DUE | 0 or 1 | If present, DURATION MUST NOT be |
+ | | | present. |
+ | DURATION | 0 or 1 | If present, DUE MUST NOT be |
+ | | | present. |
+ | EXDATE | 0+ | |
+ | GEO | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+
+
+
+Daboo Standards Track [Page 61]
+
+RFC 5546 iTIP December 2009
+
+
+ | LOCATION | 0 or 1 | |
+ | PERCENT-COMPLETE | 0 or 1 | |
+ | PRIORITY | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | REQUEST-STATUS | 0+ | |
+ | RESOURCES | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | COMPLETED/NEEDS-ACTION/ |
+ | | | IN-PROCESS. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.5. Methods for VJOURNAL Components
+
+ This section defines the property set for the methods that are
+ applicable to the "VJOURNAL" calendar component.
+
+ The following summarizes the methods that are defined for the
+ "VJOURNAL" calendar component.
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 62]
+
+RFC 5546 iTIP December 2009
+
+
+ +---------+---------------------------------------------------------+
+ | Method | Description |
+ +---------+---------------------------------------------------------+
+ | PUBLISH | Post a journal entry. Used primarily as a method of |
+ | | advertising the existence of a journal entry. |
+ | | |
+ | ADD | Add one or more instances to an existing journal entry. |
+ | | |
+ | CANCEL | Cancel one or more instances of an existing journal |
+ | | entry. |
+ +---------+---------------------------------------------------------+
+
+3.5.1. PUBLISH
+
+ The "PUBLISH" method in a "VJOURNAL" calendar component has no
+ associated response. It is simply a posting of an iCalendar object
+ that may be added to a calendar. It MUST have an "Organizer". It
+ MUST NOT have "Attendees". The expected usage is for encapsulating
+ an arbitrary journal entry as an iCalendar object. The "Organizer"
+ MAY subsequently update (with another "PUBLISH" method) or cancel
+ (with a "CANCEL" method) a previously published journal entry.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +------------------------------------------------+
+ | Constraints for a METHOD:PUBLISH of a VJOURNAL |
+ +------------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be PUBLISH. |
+ | | | |
+ | VJOURNAL | 1+ | |
+ | DESCRIPTION | 1 | Can be null. |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | UID | 1 | |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | EXDATE | 0+ | |
+ | LAST-MODIFIED | 0 or 1 | |
+
+
+
+Daboo Standards Track [Page 63]
+
+RFC 5546 iTIP December 2009
+
+
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | RRULE | 0 or 1 | |
+ | SEQUENCE | 0 or 1 | MUST be present if non-zero. MAY |
+ | | | be present if zero. |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | DRAFT/FINAL/CANCELLED. |
+ | SUMMARY | 0 or 1 | Can be null. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | ATTENDEE | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.5.2. ADD
+
+ The "ADD" method allows the "Organizer" to add one or more new
+ instances to an existing "VJOURNAL" using a single iTIP message
+ without having to send the entire "VJOURNAL" with all the existing
+ instance data, as it would have to do if the "REQUEST" method were
+ used.
+
+ The "UID" must be that of the existing journal entry. If the "UID"
+ property value in the "ADD" is not found on the recipient's calendar,
+ then the recipient MAY treat the "ADD" as a "PUBLISH".
+
+ When handling an "ADD" message, the "Attendee" treats each component
+ in the "ADD" message as if it were referenced via an "RDATE" in the
+ main component. There is no response to the "Organizer".
+
+
+
+Daboo Standards Track [Page 64]
+
+RFC 5546 iTIP December 2009
+
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+ +--------------------------------------------+
+ | Constraints for a METHOD:ADD of a VJOURNAL |
+ +--------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be ADD. |
+ | | | |
+ | VJOURNAL | 1 | |
+ | DESCRIPTION | 1 | Can be null. |
+ | DTSTAMP | 1 | |
+ | DTSTART | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | MUST be greater than 0. |
+ | UID | 1 | MUST match that of the original |
+ | | | journal. |
+ | ATTACH | 0+ | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | RELATED-TO | 0+ | |
+ | STATUS | 0 or 1 | MAY be one of |
+ | | | DRAFT/FINAL/CANCELLED. |
+ | SUMMARY | 0 or 1 | Can be null. |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | ATTENDEE | 0 | |
+ | EXDATE | 0 | |
+ | RECURRENCE-ID | 0 | |
+ | REQUEST-STATUS | 0 | |
+ | RDATE | 0 | |
+ | RRULE | 0 | |
+ | | | |
+ | VALARM | 0+ | |
+ | | | |
+ | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+
+
+
+Daboo Standards Track [Page 65]
+
+RFC 5546 iTIP December 2009
+
+
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.5.3. CANCEL
+
+ The "CANCEL" method in a "VJOURNAL" calendar component is used to
+ send a cancellation notice of an existing journal entry. The message
+ is sent by the "Organizer" of a journal entry. For a recurring
+ journal entry, either the whole journal entry or instances of a
+ journal entry may be cancelled. To cancel the complete range of a
+ recurring journal entry, the "UID" property value for the journal
+ entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be
+ specified in the "CANCEL" method. In order to cancel an individual
+ instance of the journal entry, the "RECURRENCE-ID" property value for
+ the journal entry MUST be specified in the "CANCEL" method.
+
+ There are two options for canceling a sequence of instances of a
+ recurring "VJOURNAL" calendar component:
+
+ a. The "RECURRENCE-ID" property for an instance in the sequence MUST
+ be specified with the "RANGE" property parameter value of
+ "THISANDFUTURE" to indicate cancellation of the specified
+ "VJOURNAL" calendar component and all instances after.
+
+ b. Individual recurrence instances may be cancelled by specifying
+ multiple "VJOURNAL" components each with a "RECURRENCE-ID"
+ property corresponding to one of the instances to be cancelled.
+
+ When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be
+ incremented as described in Section 2.1.4.
+
+ This method type is an iCalendar object that conforms to the
+ following property constraints:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 66]
+
+RFC 5546 iTIP December 2009
+
+
+ +-----------------------------------------------+
+ | Constraints for a METHOD:CANCEL of a VJOURNAL |
+ +-----------------------------------------------+
+
+ +--------------------+----------+-----------------------------------+
+ | Component/Property | Presence | Comment |
+ +--------------------+----------+-----------------------------------+
+ | METHOD | 1 | MUST be CANCEL. |
+ | | | |
+ | VJOURNAL | 1+ | All MUST have the same UID. |
+ | DTSTAMP | 1 | |
+ | ORGANIZER | 1 | |
+ | SEQUENCE | 1 | |
+ | UID | 1 | MUST be the UID of the original |
+ | | | REQUEST. |
+ | ATTACH | 0+ | |
+ | ATTENDEE | 0 | |
+ | CATEGORIES | 0+ | |
+ | CLASS | 0 or 1 | |
+ | COMMENT | 0+ | |
+ | CONTACT | 0+ | |
+ | CREATED | 0 or 1 | |
+ | DESCRIPTION | 0 or 1 | |
+ | DTSTART | 0 or 1 | |
+ | EXDATE | 0+ | |
+ | LAST-MODIFIED | 0 or 1 | |
+ | RDATE | 0+ | |
+ | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
+ | | | of a recurring calendar |
+ | | | component. Otherwise, it MUST |
+ | | | NOT be present. |
+ | RELATED-TO | 0+ | |
+ | RRULE | 0 or 1 | |
+ | STATUS | 0 or 1 | MAY be present; MUST be CANCELLED |
+ | | | if present. |
+ | SUMMARY | 0 or 1 | |
+ | URL | 0 or 1 | |
+ | IANA-PROPERTY | 0+ | |
+ | X-PROPERTY | 0+ | |
+ | REQUEST-STATUS | 0 | |
+ | | | |
+ | VALARM | 0 | |
+ | | | |
+ | VTIMEZONE | 0+ | MUST be present if any date/time |
+ | | | refers to a timezone. |
+ | | | |
+ | IANA-COMPONENT | 0+ | |
+ | X-COMPONENT | 0+ | |
+
+
+
+Daboo Standards Track [Page 67]
+
+RFC 5546 iTIP December 2009
+
+
+ | | | |
+ | VEVENT | 0 | |
+ | | | |
+ | VFREEBUSY | 0 | |
+ | | | |
+ | VTODO | 0 | |
+ +--------------------+----------+-----------------------------------+
+
+3.6. Status Replies
+
+ The "REQUEST-STATUS" property is used to convey status information
+ about a "REPLY", "COUNTER", or "DECLINECOUNTER" iTIP message. The
+ codes listed in the table below SHOULD be used. If the "REQUEST-
+ STATUS" property is not present in one of these iTIP messages, then a
+ status code of "2.0" (success) MUST be assumed.
+
+ This specification adds a new IANA registry for "REQUEST-STATUS"
+ property values, as defined in Section 7, which includes a new
+ registration template for defining the specific components of the
+ "REQUEST-STATUS" property value. Additional codes MAY be used,
+ provided the process described in Section 8.2.1 of [RFC5545] is used
+ to register them.
+
+ This specification allows for multiple "REQUEST-STATUS" properties to
+ be returned in iCalendar components in the appropriate iTIP messages.
+ When multiple "REQUEST-STATUS" properties are present, the following
+ restrictions apply:
+
+ 1. Within any one component, the "top-level" numeric value of the
+ "short return status code" MUST be the same for all "REQUEST-
+ STATUS" properties, i.e., there cannot be a mixture of, e.g.,
+ 2.xx and 5.xx codes within a single component.
+
+ 2. Across all components in the iTIP message, the following applies:
+
+ A. If any one component would have a 5.xx code, then either all
+ components MUST have a code in that range or "REQUEST-STATUS"
+ MUST NOT be present in the other components if a 5.xx code is
+ not appropriate for those components.
+
+ B. Otherwise, if any one component would have a 3.xx code, then
+ either all components MUST have a code in that range or
+ "REQUEST-STATUS" MUST NOT be present in the other components
+ if a 3.xx code is not appropriate for those components.
+
+ C. 2.xx and 4.xx codes can be used in different components,
+ provided that each component follows the restriction in (1)
+ above.
+
+
+
+Daboo Standards Track [Page 68]
+
+RFC 5546 iTIP December 2009
+
+
+ The following "REQUEST-STATUS" codes are defined (any "Offending
+ Data" MAY be specified in the "REQUEST-STATUS" value as the extdata
+ field):
+
+3.6.1. Status Code 2.0
+
+ Status Code: 2.0
+
+ Status Description: Success.
+
+ Status Exception Data: None.
+
+ Description: iTIP operation succeeded.
+
+3.6.2. Status Code 2.1
+
+ Status Code: 2.1
+
+ Status Description: Success, but fallback taken on one or more
+ property values.
+
+ Status Exception Data: Property name and value MAY be specified.
+
+ Description: iTIP operation succeeded with fallback on one or more
+ property values.
+
+3.6.3. Status Code 2.2
+
+ Status Code: 2.2
+
+ Status Description: Success; invalid property ignored.
+
+ Status Exception Data: Property name MAY be specified.
+
+ Description: iTIP operation succeeded but a property was ignored.
+
+3.6.4. Status Code 2.3
+
+ Status Code: 2.3
+
+ Status Description: Success; invalid property parameter ignored.
+
+ Status Exception Data: Property parameter name and value MAY be
+ specified.
+
+ Description: iTIP operation succeeded but a property parameter was
+ ignored because it was invalid.
+
+
+
+
+Daboo Standards Track [Page 69]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.5. Status Code 2.4
+
+ Status Code: 2.4
+
+ Status Description: Success; unknown, non-standard property ignored.
+
+ Status Exception Data: Non-standard property name MAY be specified.
+
+ Description: iTIP operation succeeded but a property parameter was
+ ignored because it was unknown.
+
+3.6.6. Status Code 2.5
+
+ Status Code: 2.5
+
+ Status Description: Success; unknown, non-standard property value
+ ignored.
+
+ Status Exception Data: Property and non-standard value MAY be
+ specified.
+
+ Description: iTIP operation succeeded but a property was ignored
+ because its value was unknown.
+
+3.6.7. Status Code 2.6
+
+ Status Code: 2.6
+
+ Status Description: Success; invalid calendar component ignored.
+
+ Status Exception Data: Calendar component sentinel (e.g., BEGIN:
+ ALARM) MAY be specified.
+
+ Description: iTIP operation succeeded but a component was ignored
+ because it was invalid.
+
+3.6.8. Status Code 2.7
+
+ Status Code: 2.7
+
+ Status Description: Success; request forwarded to Calendar User.
+
+ Status Exception Data: Original and forwarded calendar user
+ addresses MAY be specified.
+
+ Description: iTIP operation succeeded, and the request was forwarded
+ to another Calendar User.
+
+
+
+
+Daboo Standards Track [Page 70]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.9. Status Code 2.8
+
+ Status Code: 2.8
+
+ Status Description: Success; repeating event ignored. Scheduled as
+ a single component.
+
+ Status Exception Data: RRULE or RDATE property name and value MAY be
+ specified.
+
+ Description: iTIP operation succeeded but a repeating event was
+ truncated to a single instance.
+
+3.6.10. Status Code 2.9
+
+ Status Code: 2.9
+
+ Status Description: Success; truncated end date time to date
+ boundary.
+
+ Status Exception Data: DTEND property value MAY be specified.
+
+ Description: iTIP operation succeeded but the end time was truncated
+ to a date boundary.
+
+3.6.11. Status Code 2.10
+
+ Status Code: 2.10
+
+ Status Description: Success; repeating VTODO ignored. Scheduled as
+ a single VTODO.
+
+ Status Exception Data: RRULE or RDATE property name and value MAY be
+ specified.
+
+ Description: iTIP operation succeeded but a repeating to-do was
+ truncated to a single instance.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 71]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.12. Status Code 2.11
+
+ Status Code: 2.11
+
+ Status Description: Success; unbounded RRULE clipped at some finite
+ number of instances.
+
+ Status Exception Data: RRULE property name and value MAY be
+ specified. Number of instances MAY also be specified.
+
+ Description: iTIP operation succeeded but an unbounded repeating
+ object was clipped to a finite number of instances.
+
+3.6.13. Status Code 3.0
+
+ Status Code: 3.0
+
+ Status Description: Invalid property name.
+
+ Status Exception Data: Property name MAY be specified.
+
+ Description: iTIP operation failed because of an invalid property
+ name.
+
+3.6.14. Status Code 3.1
+
+ Status Code: 3.1
+
+ Status Description: Invalid property value.
+
+ Status Exception Data: Property name and value MAY be specified.
+
+ Description: iTIP operation failed because of an invalid property
+ value.
+
+3.6.15. Status Code 3.2
+
+ Status Code: 3.2
+
+ Status Description: Invalid property parameter.
+
+ Status Exception Data: Property parameter name and value MAY be
+ specified.
+
+ Description: iTIP operation failed because of an invalid property
+ parameter.
+
+
+
+
+
+Daboo Standards Track [Page 72]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.16. Status Code 3.3
+
+ Status Code: 3.3
+
+ Status Description: Invalid property parameter value.
+
+ Status Exception Data: Property parameter name and value MAY be
+ specified.
+
+ Description: iTIP operation failed because of an invalid property
+ parameter value.
+
+3.6.17. Status Code 3.4
+
+ Status Code: 3.4
+
+ Status Description: Invalid calendar component sequence.
+
+ Status Exception Data: Calendar component sentinel MAY be specified
+ (e.g., BEGIN:VTIMEZONE).
+
+ Description: iTIP operation failed because of an invalid component.
+
+3.6.18. Status Code 3.5
+
+ Status Code: 3.5
+
+ Status Description: Invalid date or time.
+
+ Status Exception Data: Date/time value(s) MAY be specified.
+
+ Description: iTIP operation failed because of an invalid date or
+ time property.
+
+3.6.19. Status Code 3.6
+
+ Status Code: 3.6
+
+ Status Description: Invalid rule.
+
+ Status Exception Data: RRULE property value MAY be specified.
+
+ Description: iTIP operation failed because of an invalid rule
+ property.
+
+
+
+
+
+
+
+Daboo Standards Track [Page 73]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.20. Status Code 3.7
+
+ Status Code: 3.7
+
+ Status Description: Invalid Calendar User.
+
+ Status Exception Data: ATTENDEE property value MAY be specified.
+
+ Description: iTIP operation failed because of an invalid ATTENDEE
+ property.
+
+3.6.21. Status Code 3.8
+
+ Status Code: 3.8
+
+ Status Description: No authority.
+
+ Status Exception Data: METHOD and ATTENDEE property values MAY be
+ specified.
+
+ Description: iTIP operation failed because an Attendee does not have
+ suitable privileges for the operation.
+
+3.6.22. Status Code 3.9
+
+ Status Code: 3.9
+
+ Status Description: Unsupported version.
+
+ Status Exception Data: VERSION property name and value MAY be
+ specified.
+
+ Description: iTIP operation failed because the calendar data version
+ is not supported.
+
+3.6.23. Status Code 3.10
+
+ Status Code: 3.10
+
+ Status Description: Request entity too large.
+
+ Status Exception Data: None.
+
+ Description: iTIP operation failed because the calendar data was too
+ large.
+
+
+
+
+
+
+Daboo Standards Track [Page 74]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.24. Status Code 3.11
+
+ Status Code: 3.11
+
+ Status Description: Required component or property missing.
+
+ Status Exception Data: Component or property name MAY be specified.
+
+ Description: iTIP operation failed because the calendar data did not
+ contain a required property or component.
+
+3.6.25. Status Code 3.12
+
+ Status Code: 3.12
+
+ Status Description: Unknown component or property found.
+
+ Status Exception Data: Component or property name MAY be specified.
+
+ Description: iTIP operation failed because the calendar data
+ contained an unknown property or component.
+
+3.6.26. Status Code 3.13
+
+ Status Code: 3.13
+
+ Status Description: Unsupported component or property found.
+
+ Status Exception Data: Component or property name MAY be specified.
+
+ Description: iTIP operation failed because the calendar data
+ contained an unsupported property or component.
+
+3.6.27. Status Code 3.14
+
+ Status Code: 3.14
+
+ Status Description: Unsupported capability.
+
+ Status Exception Data: METHOD or action MAY be specified.
+
+ Description: iTIP operation failed because the operation is not
+ supported.
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 75]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.28. Status Code 4.0
+
+ Status Code: 4.0
+
+ Status Description: Event conflict. Date/time is busy.
+
+ Status Exception Data: DTSTART and DTEND property names and values
+ MAY be specified.
+
+ Description: iTIP operation failed because the event overlaps the
+ date and time of another event.
+
+3.6.29. Status Code 5.0
+
+ Status Code: 5.0
+
+ Status Description: Request not supported.
+
+ Status Exception Data: METHOD property value MAY be specified.
+
+ Description: iTIP operation failed because the operation is not
+ supported.
+
+3.6.30. Status Code 5.1
+
+ Status Code: 5.1
+
+ Status Description: Service unavailable.
+
+ Status Exception Data: ATTENDEE property value MAY be specified.
+
+ Description: iTIP operation failed because scheduling is not active.
+
+3.6.31. Status Code 5.2
+
+ Status Code: 5.2
+
+ Status Description: Invalid calendar service.
+
+ Status Exception Data: ATTENDEE property value MAY be specified.
+
+ Description: iTIP operation failed because there is no scheduling
+ capability.
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 76]
+
+RFC 5546 iTIP December 2009
+
+
+3.6.32. Status Code 5.3
+
+ Status Code: 5.3
+
+ Status Description: No scheduling support for user.
+
+ Status Exception Data: ATTENDEE property value MAY be specified.
+
+ Description: iTIP operation failed because scheduling is not enabled
+ for an Attendee.
+
+3.7. Implementation Considerations
+
+3.7.1. Working With Recurrence Instances
+
+ iCalendar includes a recurrence grammar to represent recurring
+ events. The benefit of such a grammar is the ability to represent a
+ number of events in a single object. However, while this simplifies
+ creation of a recurring event, meeting instances still need to be
+ referenced. For instance, an "Attendee" may decline the third
+ instance of a recurring Friday event. Similarly, the "Organizer" may
+ change the time or location to a single instance of the recurring
+ event.
+
+ Since implementations may elect to store recurring events as either a
+ single event object or a collection of discrete, related event
+ objects, the protocol is designed so that each recurring instance may
+ be both referenced and versioned. Hence, implementations that choose
+ to maintain per-instance properties (such as "ATTENDEE" property
+ "PARTSTAT" parameter) may do so. However, the protocol does not
+ require per-instance recognition unless the instance itself must be
+ renegotiated.
+
+ The scenarios for recurrence instance referencing are listed below.
+ For purposes of simplification, a change to an event refers to a
+ "trigger property." That is, a property that has a substantive
+ effect on the meeting itself, such as start time, location, due date
+ (for "VTODO" calendar components), and possibly description.
+
+ "Organizer"-initiated actions:
+
+ o deletes or changes a single instance of a recurring event
+
+ o makes changes that affect all future instances
+
+ o makes changes that affect all previous instances
+
+ o deletes or modifies a previously changed instance
+
+
+
+Daboo Standards Track [Page 77]
+
+RFC 5546 iTIP December 2009
+
+
+ "Attendee"-initiated actions:
+
+ o changes status for a particular recurrence instance
+
+ o sends a "COUNTER" for a particular recurrence instance
+
+ An instance of a recurring event is assigned a unique identification,
+ "RECURRENCE-ID" property, when that instance is renegotiated.
+ Negotiation may be necessary when a substantive change to the event
+ or to-do has been made (such as changing the start time, end time,
+ due date, or location). The "Organizer" can identify a specific
+ recurrence instance using the "RECURRENCE-ID" property. The property
+ value is equal to the date/time of the instance. If the "Organizer"
+ wishes to change the "DTSTART", the original, unmodified "DTSTART"
+ value of the instance is used as the value "RECURRENCE-ID" property,
+ and the new "DTSTART" and "DTEND" values reflect the change.
+
+3.7.2. Attendee Property Considerations
+
+ The "ORGANIZER" property is required on published events, to-dos, and
+ journal entries for two reasons. First, only the "Organizer" is
+ allowed to update and redistribute an event or to-do component. It
+ follows that the "ORGANIZER" property MUST be present in the event,
+ to-do, or journal entry component so that the CUA has a basis for
+ authorizing an update. Second, it is prudent to provide a point of
+ contact for anyone who receives a published component, in case of
+ problems.
+
+ Email addresses that correspond to groups of "Calendar Users" could
+ be specified as a mailto: URI [RFC2368] calendar user address.
+ Sending email to such an address results in email being sent to
+ multiple recipients. Such an address may be used as the value of an
+ "ATTENDEE" property. Thus, it is possible that the recipient of a
+ "REQUEST" does not appear explicitly in the list.
+
+ It is recommended that the general approach to finding a "Calendar
+ User" in an "Attendee" list be as follows:
+
+ 1. Search for the "Calendar User" in the "Attendee" list where
+ "CUTYPE=INDIVIDUAL"
+
+ 2. Failing (1), look for "Attendees" where "CUTYPE=GROUP" or
+ "CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User"
+ is a member of one of these groups. If so, the "REPLY" method
+ sent to the "Organizer" MUST contain a new "ATTENDEE" property in
+ which:
+
+ * the "TYPE" property parameter is set to INDIVIDUAL
+
+
+
+Daboo Standards Track [Page 78]
+
+RFC 5546 iTIP December 2009
+
+
+ * the "MEMBER" property parameter is set to the name of the
+ group
+
+ 3. Failing (2), the CUA MAY ignore or accept the request as the
+ "Calendar User" wishes.
+
+3.7.3. Extension Tokens
+
+ To make iCalendar objects extensible, new component, property, or
+ property parameters can be used. Two types of extensions are defined
+ by [RFC5545]: IANA-registered tokens ("iana-token") and experimental
+ use tokens ("x-name"). A client SHOULD save "iana-token's" and MAY
+ use them in replies. A client MAY save "x-name's" and MAY use them
+ in replies. When delegating or forwarding messages to other CUs, a
+ client SHOULD include "iana-token's" and "x-names's".
+
+4. Examples
+
+4.1. Published Event Examples
+
+ In the calendaring and scheduling context, publication refers to the
+ one-way transfer of event information. Consumers of published events
+ simply incorporate the event into a calendar. No reply is expected.
+ Individual "A" publishes an event. Individual "B" reads the event
+ and incorporates it into their calendar. Events are published in
+ several ways, including embedding the event as an object in a web
+ page, emailing the event to a distribution list, or posting the event
+ to a newsgroup.
+
+ The table below illustrates the sequence of events between the
+ publisher and the consumers of a published event.
+
+ +----------------+-----------------------+--------------------------+
+ | Action | Organizer | Receiver |
+ +----------------+-----------------------+--------------------------+
+ | Publish an | "A" sends or posts a | "B" reads a published |
+ | event | PUBLISH message. | event. |
+ | | | |
+ | Publish an | "A" sends or posts a | "B" reads the updated |
+ | updated event | PUBLISH message. | event. |
+ | | | |
+ | Cancel a | "A" sends or posts a | "B" reads the canceled |
+ | published | CANCEL message. | event publication. |
+ | event | | |
+ +----------------+-----------------------+--------------------------+
+
+
+
+
+
+
+Daboo Standards Track [Page 79]
+
+RFC 5546 iTIP December 2009
+
+
+4.1.1. A Minimal Published Event
+
+ The iCalendar object below describes a single event that begins on
+ July 1, 1997 at 20:00 UTC. This event contains the minimum set of
+ properties for a "PUBLISH" for a "VEVENT" calendar component.
+
+ BEGIN:VCALENDAR
+ METHOD:PUBLISH
+ PRODID:-//Example/ExampleCalendarClient//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a at example.com
+ DTSTART:19970701T200000Z
+ DTSTAMP:19970611T190000Z
+ SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
+ UID:0981234-1234234-23 at 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 at example.com
+ DTSTAMP:19970612T190000Z
+ DTSTART:19970701T210000Z
+ DTEND:19970701T230000Z
+ SEQUENCE:1
+ UID:0981234-1234234-23 at 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 at example.com
+ COMMENT:DUKES forfeit the game
+ SEQUENCE:2
+ UID:0981234-1234234-23 at 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 at 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 at example.com
+ RELATED-TO:0981234-1234234-14 at 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 at example.com
+ DTSTAMP:19970614T190000Z
+ UID:0981234-1234234-23 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b at example.com
+
+
+
+Daboo Standards Track [Page 84]
+
+RFC 5546 iTIP December 2009
+
+
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d at example.com
+ ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big at example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e at example.com
+ DTSTAMP:19970611T190000Z
+ DTSTART:19970701T200000Z
+ DTEND:19970701T2100000Z
+ SUMMARY:Conference
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ORGANIZER:mailto:a at example.com
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d at example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
+ CUTYPE=ROOM:mailto:conf at example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e at example.com
+ DTSTART:19970701T180000Z
+ DTEND:19970701T190000Z
+ SUMMARY:Phone Conference
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c at example.com
+ DTSTART:19970701T190000Z
+ DTEND:19970701T200000Z
+ SUMMARY:Discuss the Merits of the election results
+ LOCATION:Green Conference Room
+ UID:calsrv.example.com-873970198738777a at 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 at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c at 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 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c at 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 at 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 at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b at example.com
+ COMMENT:Sorry, I cannot change this meeting time
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
+ TO="mailto:e at example.com":mailto:c at example.com
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
+ TO="mailto:e at example.com":mailto:c at example.com
+ ATTENDEE;RSVP=TRUE;
+ DELEGATED-FROM="mailto:c at example.com":mailto:e at example.com
+ DTSTART:19970701T180000Z
+ DTEND:19970701T200000Z
+ SUMMARY:Phone Conference
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
+ FROM="mailto:c at example.com":mailto:e at example.com
+ ATTENDEE;PARTSTAT=DELEGATED;
+ DELEGATED-TO="mailto:e at example.com":mailto:c at example.com
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE;PARTSTAT=DELEGATED;
+ DELEGATED-TO="mailto:e at example.com":mailto:c at example.com
+ ATTENDEE;PARTSTAT=DECLINED;
+ DELEGATED-FROM="mailto:c at example.com":mailto:e at example.com
+ COMMENT:Sorry, I will be out of town at that time.
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE;PARTSTAT=DECLINED;
+ DELEGATED-FROM="mailto:c at example.com":mailto:e at example.com
+ ATTENDEE;RSVP=TRUE:mailto:c at example.com
+ UID:calsrv.example.com-873970198738777 at example.com
+ SEQUENCE:0
+ SUMMARY:Phone Conference
+ DTSTART:19970701T180000Z
+ DTEND:19970701T200000Z
+ DTSTAMP:19970614T200000Z
+ COMMENT:DELEGATE (ATTENDEE mailto:e at 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 at example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL;mailto:a at example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:b at example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c at example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d at example.com
+ COMMENT:Mr. B cannot attend. It's raining. Lets cancel.
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE:mailto:b at example.com
+ COMMENT:You're off the hook for this meeting
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c at example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d at example.com
+ ATTENDEE;CUTYPE=ROOM:mailto:cr_big at example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;
+ RSVP=FALSE:mailto:e at 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 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:mailto:b at example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c at example.com
+ ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d at example.com
+ DTSTAMP:19970611T190000Z
+ DTSTART:19970701T200000Z
+ DTEND:19970701T203000Z
+ RRULE:FREQ=WEEKLY
+ SUMMARY:Phone Conference
+ UID:123456 at 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 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR:mailto:a at example.com
+ ATTENDEE:mailto:b at example.com
+ ATTENDEE:mailto:c at example.com
+ DTSTAMP:19970613T190000Z
+ DTSTART:19970701T080000Z
+ DTEND:19970701T200000
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE:mailto:b at example.com
+ DTSTART:19970701T080000Z
+ DTEND:19970701T200000Z
+ UID:calsrv.example.com-873970198738777 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;
+ CUTYPE=INDIVIDUAL:a at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:b at example.fr
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:c at 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 at 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 at 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 at 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 at example.com
+ SEQUENCE:0
+ RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE:mailto:b at example.com
+ ATTENDEE:mailto:c at example.com
+ ATTENDEE:mailto:d at 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 at example.com
+ RECURRENCE-ID:19970701T210000Z
+ SEQUENCE:1
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE:mailto:b at example.com
+ ATTENDEE:mailto:c at example.com
+ ATTENDEE:mailto:d at 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 at example.com
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE:mailto:b at example.com
+ ATTENDEE:mailto:c at example.com
+ ATTENDEE:mailto:d at 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 at example.com
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE:mailto:b at example.com
+ ATTENDEE:mailto:c at example.com
+ ATTENDEE:mailto:d at 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 at example.com
+ RECURRENCE-ID;THISANDFUTURE:19970901T210000Z
+ SEQUENCE:3
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE:mailto:c at example.com
+ ATTENDEE;RSVP=TRUE:mailto:d at 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 at example.com
+ SEQUENCE:4
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE:mailto:c at example.com
+ ATTENDEE;RSVP=TRUE:mailto:d at 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 at example.com
+ SEQUENCE:0
+ RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at 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 at example.com
+ SEQUENCE:7
+ RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at 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 at example.com
+ SEQUENCE:0
+ RDATE:19980304T180000Z
+ RDATE:19980311T180000Z
+ RDATE:19980318T180000Z
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at 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 at example.com
+ SEQUENCE:1
+ RECURRENCE-ID:19980311T180000Z
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at 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 at example.com
+ SEQUENCE:2
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at 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 at example.com
+ SEQUENCE:2
+ RDATE:19980304T180000Z
+ RDATE:19980311T160000Z
+ RDATE:19980315T180000Z
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at 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 at example.com
+ RECURRENCE-ID:19980311T160000Z
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at 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 at example.com
+ RECURRENCE-ID:19970715T210000Z
+ SEQUENCE:4
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;RSVP=TRUE:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE:mailto:c at example.com
+ ATTENDEE;RSVP=TRUE:mailto:d at 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 at example.com
+ SEQUENCE:0
+ RRULE:FREQ=MONTHLY;BYMONTHDAY=1
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE:mailto:c at example.com
+ ATTENDEE;RSVP=TRUE:mailto:d at 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 at example.com
+ ATTENDEE:mailto:b at example.com
+ REQUEST-STATUS:3.0;Invalid Property Name;FOO
+ UID:guid-1 at 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 at example.com
+
+
+
+Daboo Standards Track [Page 109]
+
+RFC 5546 iTIP December 2009
+
+
+ ATTENDEE;ROLE=CHAIR:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE:mailto:c at example.com
+ ATTENDEE;RSVP=TRUE:mailto:d at example.com
+ DTSTART:19970701T170000Z
+ DUE:19970722T170000Z
+ PRIORITY:1
+ SUMMARY:Create the requirements document
+ UID:calsrv.example.com-873970198738777-00 at 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 at example.com
+ ATTENDEE;PARTSTAT=ACCEPTED:mailto:b at example.com
+ UID:calsrv.example.com-873970198738777-00 at 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 at example.com
+
+
+
+Daboo Standards Track [Page 110]
+
+RFC 5546 iTIP December 2009
+
+
+ ATTENDEE;ROLE=CHAIR:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d at example.com
+ UID:calsrv.example.com-873970198738777-00 at 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 at example.com
+ ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b at example.com
+ PERCENT-COMPLETE:75
+ UID:calsrv.example.com-873970198738777-00 at 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 at example.com
+ ATTENDEE;PARTSTAT=COMPLETED:mailto:d at example.com
+ UID:calsrv.example.com-873970198738777-00 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b at example.com
+ ATTENDEE;PARTSTAT=COMPLETED;CUTYPE=INDIVIDUAL:mailto:d at example.com
+ DTSTART:19970701T170000Z
+ DUE:19970722T170000Z
+ PRIORITY:1
+ SUMMARY:Create the requirements document
+ UID:calsrv.example.com-873970198738777-00 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR:mailto:a at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b at example.com
+ ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d at 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 at 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 at example.com
+ PERCENT-COMPLETE:75
+ UID:calsrv.example.com-873970198738777-00 at 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 at 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 at example.com
+ RELATED-TO:0981234-1234234-2402-35 at 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 at example.com":
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example/ExampleCalendarClient//EN
+ METHOD:REFRESH
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:mailto:a at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE:mailto:b at example.com
+ ATTENDEE:mailto:c at example.com
+ ATTENDEE:mailto:d at example.com
+ UID:guid-1-12345 at 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 at 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 at example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a at example.com
+ ATTENDEE:mailto:b at 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 at 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 at example.com
+ ATTENDEE:mailto:b at example.com
+ UID:example-12345 at 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 at daboo.name
+ URI: http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Standards Track [Page 133]
+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20100427/3480d57f/attachment-0001.html>
More information about the calendarserver-changes
mailing list