summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2446.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2446.txt')
-rw-r--r--doc/rfc/rfc2446.txt6107
1 files changed, 6107 insertions, 0 deletions
diff --git a/doc/rfc/rfc2446.txt b/doc/rfc/rfc2446.txt
new file mode 100644
index 0000000..8e038a2
--- /dev/null
+++ b/doc/rfc/rfc2446.txt
@@ -0,0 +1,6107 @@
+
+
+
+
+
+
+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@example.com
+ DTSTART:19970701T200000Z
+ DTSTAMP:19970611T190000Z
+ SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
+ UID:0981234-1234234-23@example.com
+ END:VEVENT
+ END:VCALENDAR
+
+4.1.2 Changing A Published Event
+
+ The iCalendar object below describes an update to the event described
+ in 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@example.com
+ DTSTAMP:19970612T190000Z
+ DTSTART:19970701T210000Z
+ DTEND:19970701T230000Z
+ SEQUENCE:1
+ UID:0981234-1234234-23@example.com
+ SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
+ END:VEVENT
+ END:VCALENDAR
+
+ The "UID" property is used by the client to identify the event. The
+ "SEQUENCE" property indicates that this is a change to the event. The
+ event with a matching UID and sequence number 0 is superseded by this
+ event.
+
+ The "SEQUENCE" property provides a reliable way to distinguish
+ different versions of the same event. Each time an event is
+ published, its sequence number is incremented. If a client receives
+ 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@example.com
+ COMMENT:DUKES forfeit the game
+ SEQUENCE:2
+ UID:0981234-1234234-23@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@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@example.com
+ RELATED-TO:0981234-1234234-14@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@example.com
+ DTSTAMP:19970614T190000Z
+ UID:0981234-1234234-23@example.com
+ DTSTART;VALUE=DATE:19970714
+ RRULE:FREQ=YEARLY;INTERVAL=1
+ SUMMARY: Bastille Day
+ END:VEVENT
+ END:VCALENDAR
+
+4.2 Group Event Examples
+
+ Group events are distinguished from published events in that they
+ have "Attendees" and 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@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
+
+
+
+Silverberg, et. al. Standards Track [Page 64]
+
+RFC 2446 iTIP November 1998
+
+
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
+ ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
+ DTSTAMP:19970611T190000Z
+ DTSTART:19970701T200000Z
+ DTEND:19970701T2000000Z
+ SUMMARY:Conference
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.2 Reply To A Group Event Request
+
+ Attendee "B" accepts the meeting.
+
+ BEGIN:VCALENDAR
+ PRODID:-//ACME/DesktopCalendar//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VEVENT
+ ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com
+ ORGANIZER:MAILTO:A@example.com
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ REQUEST-STATUS:2.0;Success
+ DTSTAMP:19970612T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+ "B" could have declined the meeting or indicated tentative acceptance
+ by setting the "ATTENDEE" "partstat" parameter to "declined" or
+ "tentative", respectively. Also, "REQUEST-STATUS" is not required in
+ successful transactions.
+
+4.2.3 Update An Event
+
+ The event is moved to a different time. The combination of the "UID"
+ property (unchanged) and the "SEQUENCE" (bumped to 1) properties
+ indicate the update.
+
+ BEGIN:VCALENDAR
+ PRODID:-//ACME/DesktopCalendar//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:Mailto:A@example.com
+
+
+
+Silverberg, et. al. Standards Track [Page 65]
+
+RFC 2446 iTIP November 1998
+
+
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
+ CUTYPE=ROOM:Mailto:Conf@example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
+ DTSTART:19970701T180000Z
+ DTEND:19970701T190000Z
+ SUMMARY:Phone Conference
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:1
+ DTSTAMP:19970613T190000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.4 Countering an Event Proposal
+
+ "A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal to
+ "A" to change the time and location.
+
+ "A" sends the following "REQUEST":
+
+ BEGIN:VCALENDAR
+ PRODID:-//ACME/DesktopCalendar//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
+ DTSTART:19970701T190000Z
+ DTEND:19970701T200000Z
+ SUMMARY:Discuss the Merits of the election results
+ LOCATION:Green Conference Room
+ UID:calsrv.example.com-873970198738777a@example.com
+ SEQUENCE:0
+ DTSTAMP:19970611T190000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ "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@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@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@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@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@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@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@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
+ COMMENT:Sorry, I cannot change this meeting time
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ DTSTAMP:19970614T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.5 Delegating an Event
+
+ When delegating an event request to another "Calendar User", the
+ "Delegator" must both update the "Organizer" with a "REPLY" and send
+ a request to the "Delegate". There is currently no protocol
+ limitation to delegation depth. It is possible for the original
+
+ delegate to delegate the meeting to someone else, and so on. When a
+ request is delegated from one CUA to another there are a number of
+ responsibilities required of the "Delegator". The "Delegator" MUST:
+
+ . 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@Example.com
+ ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
+ TO="Mailto:E@example.com":Mailto:C@example.com
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ REQUEST-STATUS:2.0;Success
+ DTSTAMP:19970611T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+ Attendee "C" delegates presence at the meeting to "E".
+
+ BEGIN:VCALENDAR
+ PRODID:-//ACME/DesktopCalendar//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
+ TO="Mailto:E@example.com":Mailto:C@example.com
+ ATTENDEE;RSVP=TRUE;
+ DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
+ DTSTART:19970701T180000Z
+ DTEND:19970701T200000Z
+ SUMMARY:Phone Conference
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ STATUS:CONFIRMED
+ DTSTAMP:19970611T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.6 Delegate Accepts the Meeting
+
+ To accept a delegated meeting, the delegate, "E", sends the following
+ message to "A" and "C":
+
+ BEGIN:VCALENDAR
+ PRODID:-//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@Example.com
+ ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
+ FROM="Mailto:C@example.com":Mailto:E@example.com
+ ATTENDEE;PARTSTAT=DELEGATED;
+ DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ REQUEST-STATUS:2.0;Success
+ DTSTAMP:19970614T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.7 Delegate Declines the Meeting
+
+ In this example the "Delegate" declines the meeting request and sets
+ the "ATTENDEE" property "partstat" parameter to "DECLINED". The
+ "Organizer" SHOULD resend the "REQUEST" to "C" with the "partstat"
+ parameter of the "Delegate" set to "declined". This lets the
+ "Delegator" know that the "Delegate" has declined and provides an
+ opportunity to the "Delegator" to either accept the request or
+ delegate it to another CU.
+
+ 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@Example.com
+ ATTENDEE;PARTSTAT=DELEGATED;
+ DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com
+ ATTENDEE;PARTSTAT=DECLINED;
+ DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
+ COMMENT:Sorry, I will be out of town at that time.
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ REQUEST-STATUS:2.0;Success
+ DTSTAMP:19970614T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+ "A" resends the "REQUEST" method to "C". "A" may also wish to express
+ the fact that the item was delegated in the "COMMENT" property.
+
+
+
+
+
+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@Example.com
+ ATTENDEE;PARTSTAT=DECLINED;
+ DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:C@example.com
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:0
+ SUMMARY:Phone Conference
+ DTSTART:19970701T180000Z
+ DTEND:19970701T200000Z
+ DTSTAMP:19970614T200000Z
+ COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR
+ INVITATION
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.8 Forwarding an Event Request
+
+ The protocol does not prevent an "Attendee" from "forwarding" 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@example.com
+ ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com
+ ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com
+ ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
+ ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
+ COMMENT:Mr. B cannot attend. It's raining. Lets cancel.
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:1
+ STATUS:CANCELLED
+ DTSTAMP:19970613T190000Z
+ END:VEVENT
+ END:VCALENDAR
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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@example.com
+ ATTENDEE:mailto:B@example.com
+ COMMENT:You're off the hook for this meeting
+ UID:calsrv.example.com-873970198738777@example.com
+ DTSTAMP:19970613T193000Z
+ SEQUENCE:1
+ END:VEVENT
+ END:VCALENDAR
+
+ The updated master copy of the event is shown below. The "Organizer"
+ MAY resend the updated event to the remaining "Attendees". Note that
+ "B" has been removed.
+
+ BEGIN:VCALENDAR
+ PRODID:-//ACME/DesktopCalendar//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:Mailto:A@example.com
+
+
+
+Silverberg, et. al. Standards Track [Page 74]
+
+RFC 2446 iTIP November 1998
+
+
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
+ ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
+ ATTENDEE;TYPE=ROOM:CR_Big@example.com
+ ATTENDEE;ROLE=NON-PARTICIPANT;
+ RSVP=FALSE:Mailto:E@example.com
+ DTSTAMP:19970611T190000Z
+ DTSTART:19970701T200000Z
+ DTEND:19970701T203000Z
+ SUMMARY:Phone Conference
+ UID:calsrv.example.com-873970198738777@example.com
+ SEQUENCE:2
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.2.11 Replacing the Organizer
+
+ The scenario for this example begins with "A" as the "Organizer" for
+ a recurring meeting with "B", "C", and "D". "A" receives a new job
+ offer in another country and drops out of touch. "A" left no
+ forwarding address or way to be reached. Using out-of-band
+ communication, the other "Attendees" eventually learn what has
+ happened and reach an agreement that "B" should become the new
+ "Organizer" for the meeting. To do this, "B" sends out a new version
+ of the event and the other "Attendees" agree to accept "B" as the new
+ "Organizer". "B" also removes "A" from the event.
+
+ When the "Organizer" is replaced, the "SEQUENCE" property value MUST
+ be incremented.
+
+ This is the message "B" sends to "C" and "D"
+
+ BEGIN:VCALENDAR
+ PRODID:-//ACME/DesktopCalendar//EN
+ METHOD:REQUEST
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:Mailto:B@example.com
+ ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com
+ ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
+ ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
+ DTSTAMP:19970611T190000Z
+ DTSTART:19970701T200000Z
+ DTEND:19970701T203000Z
+ RRULE:FREQ=WEEKLY
+ SUMMARY:Phone Conference
+ UID:123456@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@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@example.com
+ ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
+ ATTENDEE:Mailto:B@example.com
+ ATTENDEE:Mailto:C@example.com
+ DTSTAMP:19970613T190000Z
+ DTSTART:19970701T080000Z
+ DTEND:19970701T200000
+ UID:calsrv.example.com-873970198738777@example.com
+ END:VFREEBUSY
+ END:VCALENDAR
+
+4.3.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@example.com
+ ATTENDEE:Mailto:B@example.com
+ DTSTART:19970701T080000Z
+ DTEND:19970701T200000Z
+ UID:calsrv.example.com-873970198738777@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@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A@example.COM
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@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@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@example.fr is in France where the local time on this
+ date is 9 hours ahead of PDT or 23:00. "Attendee" C@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@host1.com
+ SEQUENCE:0
+ RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE:Mailto:B@example.com
+ ATTENDEE:Mailto:C@example.com
+ ATTENDEE:Mailto:D@example.com
+ DESCRIPTION:IETF-C&S Conference Call
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970601T210000Z
+ DTEND:19970601T220000Z
+ LOCATION:Conference Call
+ DTSTAMP:19970526T083000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ The event request below is to change the time of a specific instance.
+ This changes the July 1st instance to July 3rd.
+
+ BEGIN:VCALENDAR
+ METHOD:REQUEST
+ PRODID:-//RDU Software//NONSGML HandCal//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:guid-1@host1com
+ RECURRENCE-ID:19970701T210000Z
+ SEQUENCE:1
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE:Mailto:B@example.com
+ ATTENDEE:Mailto:C@example.com
+ ATTENDEE:Mailto:D@example.com
+ DESCRIPTION:IETF-C&S Conference Call
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970703T210000Z
+ DTEND:19970703T220000Z
+ LOCATION:Conference Call
+ 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@host1.com
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE:Mailto:B@example.com
+ ATTENDEE:Mailto:C@example.com
+ ATTENDEE:Mailto:D@example.com
+ RECURRENCE-ID:19970801T210000Z
+ SEQUENCE:2
+ STATUS:CANCELLED
+ DTSTAMP:19970721T093000Z
+ END:VEVENT
+ END:VCALENDAR
+
+4.4.4 Cancel 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@host1.com
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE:Mailto:B@example.com
+ ATTENDEE:Mailto:C@example.com
+ ATTENDEE:Mailto:D@example.com
+ DTSTAMP:19970721T103000Z
+ STATUS:CANCELLED
+ SEQUENCE:3
+ END:VEVENT
+ 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@host1.com
+ RECURRENCE-ID;THISANDFUTURE:19970901T210000Z
+ SEQUENCE:3
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:C@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:D@example.com
+ DESCRIPTION:IETF-C&S Discussion
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970901T210000Z
+ DTEND:19970901T220000Z
+ LOCATION:Building 32, Microsoft, Seattle, WA
+ DTSTAMP:19970526T083000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+4.4.6 Add A New Instance To A Recurring Event
+
+ This example adds a one-time additional instance to the recurring
+ event. "Organizer" adds a second July meeting on the 15th.
+
+ BEGIN:VCALENDAR
+ METHOD:ADD
+ PRODID:-//RDU Software//NONSGML HandCal//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:123456789@host1.com
+ SEQUENCE:4
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:C@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:D@example.com
+ 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@host1.com
+ SEQUENCE:0
+ RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980303T210000Z
+ DTEND:19980303T220000Z
+ LOCATION:The White Room
+ DTSTAMP:19980301T093000Z
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ 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@host1.com
+ SEQUENCE:7
+ RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980303T210000Z
+ DTEND:19980303T220000Z
+ DTSTAMP:19980303T193000Z
+ LOCATION:The 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@host1.com
+ SEQUENCE:7
+ RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980303T210000Z
+ DTEND:19980303T220000Z
+ DTSTAMP:19980303T193000Z
+ LOCATION:The White Room
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ 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@host1.com
+ SEQUENCE:0
+ RDATE:19980304T180000Z
+ RDATE:19980311T180000Z
+ RDATE:19980318T180000Z
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980304T180000Z
+ DTEND:19980304T200000Z
+ DTSTAMP:19980303T193000Z
+ LOCATION:Conference Room A
+ STATUS:CONFIRMED
+ 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@host1.com
+ SEQUENCE:1
+ RECURRENCE-ID:19980311T180000Z
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980311T160000Z
+ DTEND:19980311T180000Z
+ DTSTAMP:19980306T193000Z
+ LOCATION:The Small conference room
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+
+
+
+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@host1.com
+ SEQUENCE:2
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980315T180000Z
+ DTEND:19980315T200000Z
+ DTSTAMP:19980307T193000Z
+ LOCATION:Conference Room A
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ 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@host1.com
+ SEQUENCE:2
+ RDATE:19980304T180000Z
+ RDATE:19980311T160000Z
+ RDATE:19980315T180000Z
+ Error! Bookmark not defined.
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ SUMMARY:Review Accounts
+ DTSTART:19980304T180000Z
+ DTEND:19980304T200000Z
+ DTSTAMP:19980303T193000Z
+ LOCATION:Conference Room A
+ STATUS:CONFIRMED
+
+
+
+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@host1.com
+ RECURRENCE-ID:19970715T210000Z
+ SEQUENCE:4
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;RSVP=TRUE:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:C@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:D@example.com
+ DESCRIPTION:IETF-C&S Conference Call
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970715T220000Z
+ DTEND:19970715T230000Z
+ LOCATION:Conference Call
+ COMMENT:May we bump this by an hour? I have a conflict
+ DTSTAMP:19970629T094000Z
+ END:VEVENT
+ END:VCALENDAR
+
+
+
+
+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@host1.com
+ SEQUENCE:0
+ RRULE:FREQ=MONTHLY;BYMONTHDAY=1
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:C@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:D@example.com
+ DESCRIPTION:IETF-C&S Conference Call
+ CLASS:PUBLIC
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970601T210000Z
+ 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@example.com
+ ATTENDEE:Mailto:B@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@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@example.com
+ ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:C@example.com
+ ATTENDEE;RSVP=TRUE:Mailto:D@example.com
+ DTSTART:19970701T170000Z
+ DUE:19970722T170000Z
+ PRIORITY:1
+ SUMMARY:Create the requirements document
+ UID:calsrv.example.com-873970198738777-00@example.com
+ SEQUENCE:0
+ DTSTAMP:19970717T200000Z
+ STATUS:Needs Action
+ END:VTODO
+ END:VCALENDAR
+
+4.5.2 A VTODO Reply
+
+ "B" accepts the to-do.
+
+ BEGIN:VCALENDAR
+ PRODID:-//ACME/DesktopCalendar//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VTODO
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com
+ UID:calsrv.example.com-873970198738777-00@example.com
+ COMMENT:I'll send you my input by 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@example.com
+ ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com
+ UID:calsrv.example.com-873970198738777-00@example.com
+ SUMMARY:Create the requirements document
+ PRIORITY:1
+ SEQUENCE:0
+ STATUS:IN-PROCESS
+ DTSTART:19970701T170000Z
+ DTSTAMP:19970717T230000Z
+ END:VTODO
+ END:VCALENDAR
+
+4.5.4 A Reply: Percent-Complete
+
+ A reply indicating the task being worked on and that "B" is 75%
+ complete with "B's" part of the assignment.
+
+ BEGIN:VCALENDAR
+ PRODID:-//ACME/DesktopCalendar//EN
+ METHOD:REPLY
+ VERSION:2.0
+ BEGIN:VTODO
+ ORGANIZER:MAILTO:A@example.com
+ ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com
+ PERCENT-COMPLETE:75
+ UID:calsrv.example.com-873970198738777-00@example.com
+ DTSTAMP:19970717T233000Z
+ SEQUENCE:0
+ END:VTODO
+ END:VCALENDAR
+
+
+
+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@example.com
+ ATTENDEE;PARTSTAT=COMPLETED:Mailto:D@example.com
+ UID:calsrv.example.com-873970198738777-00@example.com
+ DTSTAMP:19970717T233000Z
+ SEQUENCE:0
+ END:VTODO
+ END:VCALENDAR
+
+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@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B@example.com
+ ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D@example.com
+ DTSTART:19970701T170000Z
+ DUE:19970722T170000Z
+ PRIORITY:1
+ SUMMARY:Create the requirements document
+ UID:calsrv.example.com-873970198738777-00@example.com
+ SEQUENCE:1
+ DTSTAMP:19970718T100000Z
+ STATUS:IN-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@example.com
+ ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
+ ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@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@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@example.com
+ PERCENT-COMPLETE:75
+ UID:calsrv.example.com-873970198738777-00@example.com
+ DTSTAMP:19970717T233000Z
+ RECURRENCE-ID:19980101T170000Z
+ SEQUENCE:1
+ END:VTODO
+ END:VCALENDAR
+
+4.6 Journal Examples
+
+ The iCalendar object below describes a single journal entry for
+ October 2, 1997. The "RELATED-TO" property references the phone
+ conference event for which minutes were taken.
+
+ BEGIN:VCALENDAR
+ METHOD:PUBLISH
+ PRODID:-//ACME/DesktopCalendar//EN
+ VERSION:2.0
+ BEGIN:VJOURNAL
+ DTSTART:19971002T200000Z
+ ORGANIZER:MAILTO:A@Example.com
+ SUMMARY:Phone conference minutes
+ DESCRIPTION:The editors meeting was held on October 1, 1997.
+ Details are in the attached document.
+ UID:0981234-1234234-2410@example.com
+ RELATED-TO:0981234-1234234-2402-35@example.com
+ ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt
+ END:VJOURNAL
+ END:VCALENDAR
+
+4.7 Other Examples
+
+4.7.1 Event Refresh
+
+ Refresh the event with "UID" property value of "guid-1-
+ 12345@host1.com":
+
+ BEGIN:VCALENDAR
+ PRODID:-//RDU Software//NONSGML HandCal//EN
+ METHOD:REFRESH
+ VERSION:2.0
+ BEGIN:VEVENT
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE:Mailto:B@example.com
+ ATTENDEE:Mailto:C@example.com
+
+
+
+Silverberg, et. al. Standards Track [Page 94]
+
+RFC 2446 iTIP November 1998
+
+
+ ATTENDEE:Mailto:D@example.com
+ UID: guid-1-12345@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@host1.com
+ SEQUENCE:3
+ RRULE:FREQ=WEEKLY
+ RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z
+ ORGANIZER:Mailto:A@example.com
+ ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
+ ATTENDEE:Mailto:B@example.com
+ DESCRIPTION:IETF-C&S Conference Call
+ SUMMARY:IETF Calendaring Working Group Meeting
+ DTSTART:19970801T210000Z
+ DTEND:19970801T220000Z
+ RECURRENCE-ID:19970809T210000Z
+ DTSTAMP:19970726T083000
+ STATUS:CONFIRMED
+ END:VEVENT
+ END:VCALENDAR
+
+ "B" has the event with "UID" property "acme-12345@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@example.com
+ ATTENDEE:Mailto:B@example.com
+ UID:acme-12345@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@Lotus.com
+ EMAIL;TYPE=INTERNET:fdawson@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@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@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@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@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@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]
+