As per Relevance of the word component, we have this rfc below:
Network Working Group S.
Request for Comments: 2446
Category: Standards Track S.
F.
R.
ON
November 1998
iCalendar Transport-Independent Interoperability
(iTIP
Scheduling Events, BusyTime, To-dos and Journal
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document specifies how calendaring systems use iCalendar
to interoperate with other calendar systems. It does so in a
way so as to allow multiple methods of communication between systems
Subsequent documents specify interoperable methods of
between systems that use this protocol
The document outlines a model for calendar exchange that defines
static and dynamic event, to-do, journal and free/busy objects
Static objects are used to transmit information from one entity
another without the expectation of continuity or
integrity with the original item. Dynamic objects are a superset
static objects and will gracefully degrade to their
counterparts for clients that only support static objects
This document specifies an Internet protocol based on the
object specification that provides scheduling
between different calendar systems. The Internet protocol is
the "iCalendar Transport-Independent Interoperability
(iTIP)".
Silverberg, et. al. Standards Track [Page 1]
RFC 2446 iTIP November 1998
iTIP complements the iCalendar object specification by
semantics for group scheduling methods commonly available in
calendar systems. These scheduling methods permit two or
calendar systems to perform transactions such as publish, schedule
reschedule, respond to scheduling requests, negotiation of changes
cancel iCalendar-based calendar components
iTIP is defined independent of the particular transport used
transmit the scheduling information. Companion memos to iTIP
bindings of the interoperability protocol to a number of
protocols
Table of
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
This document specifies how calendaring systems use iCalendar
to interoperate with other calendar systems. In particular,
specifies how to schedule events, to-dos, or daily journal entries
It further specifies how to search for available busy
information. It does so in a general way so as to allow
methods of communication between systems. Subsequent
specify transport bindings between systems that use this protocol
This protocol is based on messages sent from an originator to one
more recipients. For certain types of messages, a recipient
reply, in order to update their status and may also
transaction/request status information. The protocol supports
ability for the message originator to modify or cancel the
message. The protocol also supports the ability for recipients
suggest changes to the originator of a message. The elements of
protocol also define the user roles for its transactions
1.1 Formatting
In order to refer to elements of the calendaring and
model, core object or interoperability protocol defined in [iCAL]
[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
document are to be interpreted as described in [RFC-2119].
Calendaring and scheduling roles are referred to in quoted-strings
text with the first character of each word in upper case.
example, "Organizer" refers to a role of a "Calendar User" (CU
within the scheduling protocol defined by [iTIP]. Calendar
defined by [iCAL] are referred to with capitalized, quoted-strings
text. All calendar components start with the letter "V". For example
"VEVENT" refers to the event calendar component, "VTODO" refers
the to-do calendar component and "VJOURNAL" refers to the
journal calendar component. Scheduling methods defined by [iTIP]
referred to with capitalized, quoted-strings of text. For example
"REQUEST" refers to the method for requesting a scheduling
component be created or modified, "REPLY" refers to the method
recipient of a request uses to update their status with
"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
the calendar address of a "Calendar User". Property
Silverberg, et. al. Standards Track [Page 5]
RFC 2446 iTIP November 1998
defined by this memo are referred to with lower case, quoted-
of text, followed by the word "parameter". For example, "value
parameter refers to the iCalendar property parameter used to
the default data type for a property value. Enumerated values
by this memo are referred to with capitalized text, either alone
followed by the word "value".
In tables, the quoted-string text is specified without quotes
order to minimize the table length
1.2 Related
Implementers will need to be familiar with several other memos that
along with this one, describe the Internet calendaring and
standards. This document, [iTIP], specifies an
protocol for scheduling between different implementations.
related documents are
[iCAL] - specifies the objects, data types, properties
property parameters used in the protocols, along with
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
definitions from these other memos. Where possible, references
made to the memo that provides for the specification of
concepts or definitions
1.3 ITIP Roles and
ITIP defines methods for exchanging [iCAL] objects for the
of group calendaring and scheduling between "Calendar Users" (CUs).
CUs take on one of two roles in iTIP. The CU who initiates
exchange takes on the role of "Organizer". For example, the CU
proposes a group meeting is the "Organizer". The CUs asked
participate in the group meeting by the "Organizer" take on the
of "Attendee". Note that "role" is also a descriptive parameter
the _ATTENDEE_ property. Its use is to convey descriptive context
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
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
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
are a subset of the above set
2 Interoperability
There are two distinct protocols relevant to interoperability:
"Application Protocol" and a "Transport Protocol". The
Protocol defines the content of the iCalendar objects sent
sender and receiver to accomplish the scheduling transactions
above. The Transport Protocol defines how the iCalendar objects
sent between the sender and receiver. This document focuses on
Application Protocol. Binding documents such as [iMIP] focus on
Transport Protocol
The connection between Sender and Receiver in the diagram
refers to the Application Protocol. The iCalendar objects passed
the Sender to the Receiver are presented in Section 3,
Protocol Elements
+----------+ +----------+
| | iTIP | |
| Sender |<-------------------->| Receiver |
| | | |
+----------+ +----------+
There are several variations of this diagram in which the Sender
Receiver take on various roles of a "Calendar User Agent" (CUA) or
"Calendar Service" (CS).
The architecture of iTIP is depicted in the diagram below.
application written to this specification may work with bindings
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
In the iTIP model, a calendar entry is created and managed by
"Organizer". The "Organizer" interacts with other CUs by sending
or more of the iTIP messages listed above. "Attendees" use
"REPLY" method to communicate their status. "Attendees" do not
direct changes to the master calendar entry. They can, however,
the "COUNTER" method to suggest changes to the "Organizer". In
case, the "Organizer" has complete control over the master
entry
2.1.1 Calendar Entry
There are two distinct states relevant to calendar entries:
overall state of the entry and the state associated with
"Attendee" to that entry
The state of an entry is defined by the "STATUS" property and
controlled by the "Organizer." There is no default value for
"STATUS" property. The "Organizer" sets the "STATUS" property to
appropriate value for each calendar entry
The state of a particular "Attendee" relative to an entry is
by the "partstat" parameter in the "ATTENDEE" property for
"Attendee". When an "Organizer" issues the initial entry, "Attendee
status is unknown. The "Organizer" specifies this by setting
"partstat" parameter to "NEEDS-ACTION". Each "Attendee"
their "ATTENDEE" property "partstat" parameter to an
value as part of a "REPLY" message sent back to the "Organizer".
2.1.2
Delegation is defined as the process by which an "Attendee"
another CU (or several CUs) the right to attend on their behalf.
"Organizer" is made aware of this change because the
"Attendee" informs the "Organizer". These steps are detailed in
REQUEST method section
Silverberg, et. al. Standards Track [Page 9]
RFC 2446 iTIP November 1998
2.1.3 Acting on Behalf of other Calendar
In many organizations one user will act on behalf of another
organize and/or respond to meeting requests. ITIP provides
mechanisms that support these activities
First, the "Organizer" is treated as a special entity, separate
"Attendees". All responses from "Attendees" flow to the "Organizer",
making it easy to separate a calendar user organizing a meeting
calendar users attending the meeting. Additionally,
provides descriptive roles for each "Attendee". For instance, a
of "chair" may be ascribed to one or more "Attendees". The "chair
and the "Organizer" may or may not be the same calendar user.
maps well to scenarios where an assistant may manage
logistics for another individual who chairs a meeting
Second, a "sent-by" parameter may be specified in either
"Organizer" or "Attendee" properties. When specified, the "sent-by
parameter indicates that the responding CU acted on behalf of
specified "Attendee" or "Organizer".
2.1.4 Component
The "SEQUENCE" property is used by the "Organizer" to
revisions to the calendar component. The rules for incrementing
"SEQUENCE" number are defined in [iCAL]. For clarity, these rules
paraphrased here in terms of how they are applied in [iTIP]. For
given "UID" in a calendar component
. For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE"
value is incremented according to the rules defined in [iCAL].
. The "SEQUENCE" property value MUST be incremented each time
"Organizer" uses the "ADD" or "CANCEL" methods
. The "SEQUENCE" property value MUST NOT be incremented when
"REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending
delegation "REQUEST".
In some circumstances the "Organizer" may not have received
to the final revision sent out. In this situation, the "Organizer
may wish to send an update "REQUEST", and set "RSVP=TRUE" for
"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
"Attendee" may not always match the "Organizer's" revision
Implementations may choose to have the CUA indicate to the CU
the response is to an entry that has been revised and allow the CU
decide whether or not to accept the response
2.1.5 Message
CUAs that handle the [iTIP] application protocol must often
a component in a calendar store with a component received in
[iTIP] message. For example, an event may be updated with a
revision of the same event. To accomplish this, a CUA must
the version of the event already in its calendar store with
version sent in the [iTIP] message. In addition to this correlation
there are several factors that can cause [iTIP] messages to arrive
an unexpected order. That is, an "Organizer" could receive a
to an earlier revision of a component AFTER receiving a reply to
later revision
To maximize interoperability and to handle messages that arrive in
unexpected order, use the following rules
1. The primary key for referencing a particular iCalendar
is the "UID" property value. To reference an instance of
recurring component, the primary key is composed of the "UID"
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,
component with the highest numeric value for the "SEQUENCE
property obsoletes all other revisions of the component
lower values
3. "Attendees" send "REPLY" messages to the "Organizer".
replies where the "UID" property value is the same, the value
the "SEQUENCE" property indicates the revision of the
to which the "Attendee" is replying. The reply with the
numeric value for the "SEQUENCE" property obsoletes all
replies with lower values
4. In situations where the "UID" and "SEQUENCE" properties match
the "DTSTAMP" property is used as the tie-breaker. The
with the latest "DTSTAMP" overrides all others. Similarly,
"Attendee" responses where the "UID" property values match
the "SEQUENCE" property values match, the response with
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
"ATTENDEE" property of a component CUAs must persist the "SEQUENCE
and "DTSTAMP" property values associated with the "Attendee's
response
3 Application Protocol
ITIP messages are "text/calendar" MIME entities that
calendaring and scheduling information. The particular type of [iCAL
message is referred to as the "method type". Each method type
identified by a "METHOD" property specified as part of
"text/calendar" content type. The table below shows
combinations of calendar components and the method types that
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
properties. Some components and properties are required, some
optional and others are excluded. The restrictions are expressed
this document using a simple "restriction table". The first
indicates the name of a component or property. Properties of
iCalendar object are not indented. Properties of a component
indented. The second column contains "MUST" if the component
property must be present, "MAY" if the component or property
optional, and "NOT" if the component or property must not be present
Entries in the second column sometimes contain comments for
clarification
Silverberg, et. al. Standards Track [Page 12]
RFC 2446 iTIP November 1998
3.1 Common Component Restriction
The restriction table below applies to properties of the
object. That is, the properties at the outermost scope. The
column uses the following values to assert whether a property
required, is optional and the number of times it may appear in
iCalendar object
Presence Value
--------------------------------------------------------------
1 One instance MUST be
1+ At least one instance MUST be
0 Instances of this property Must NOT be
0+ Multiple instances MAY be
0 or 1 Up to 1 instance of this property MAY be
---------------------------------------------------------------
The tables also call out "X-PROPERTY" and "X-COMPONENT" to
where vendor-specific properties and components can appear.
tables do not lay out the restrictions of property parameters.
restrictions are defined in [iCAL].
Component/Property
------------------- ----------------------------------------------
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
restrictions in the table below apply to any "VTIMEZONE" component
an ITIP message
Component/Property
------------------- ----------------------------------------------
VTIMEZONE 0+ MUST be present if any date/time
to
DAYLIGHT 0+ MUST be one or more of either STANDARD
COMMENT 0 or 1
DTSTART 1 MUST be local time
RDATE 0+ if present RRULE MUST NOT be
RRULE 0+ if present RDATE MUST NOT be
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
COMMENT 0 or 1
DTSTART 1 MUST be local time
RDATE 0+ if present RRULE MUST NOT be
RRULE 0+ if present RDATE MUST NOT be
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
------------------- ----------------------------------------------
VALARM 0+
ACTION 1
ATTACH 0+
DESCRIPTION 0 or 1
DURATION 0 or 1 if present REPEAT MUST be
REPEAT 0 or 1 if present DURATION MUST be
SUMMARY 0 or 1
TRIGGER 1
X-PROPERTY 0+
3.2 Methods for VEVENT Calendar
This section defines the property set restrictions for the
types that are applicable to the "VEVENT" calendar component.
method is defined using a table that clarifies the
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
"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
The "PUBLISH" method in a "VEVENT" calendar component is
unsolicited posting of an iCalendar object. Any CU may add
components to their calendar. The "Organizer" MUST be present in
published iCalendar component. "Attendees" MUST NOT be present.
expected usage is for encapsulating an arbitrary event as
iCalendar object. The "Organizer" may subsequently update (
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
following property constraints
Component/Property
------------------- ----------------------------------------------
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
recurring calendar component.
it MUST NOT be present
SEQUENCE 0 or 1 MUST be present if value is greater
0, MAY be present if 0
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be
DTEND 0 or 1 if present DURATION MUST NOT be
DURATION 0 or 1 if present DTEND MUST NOT be
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
RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/
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
a
X-COMPONENT 0+
3.2.2
The "REQUEST" method in a "VEVENT" component provides the
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,
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
"Attendee" to another CU
. For an existing "VEVENT" calendar component, changing the role
"Organizer" to another CU
The "Organizer" originates the "REQUEST". The recipients of
"REQUEST" method are the CUs invited to the event, the "Attendees".
"Attendees" use the "REPLY" method to convey attendance status to
"Organizer".
The "UID" and "SEQUENCE" properties are used to distinguish
various uses of the "REQUEST" method. If the "UID" property value
the "REQUEST" is not found on the recipient's calendar, then
"REQUEST" is for a new "VEVENT" calendar component. If the "UID
property value is found on the recipient's calendar, then
"REQUEST" is for a rescheduling, an update, or a reconfirm of
"VEVENT" calendar component
For the "REQUEST" method, multiple "VEVENT" components in a
iCalendar object are only permitted when for components with the
"UID" property. That is, a series of recurring events may
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
following property constraints
Component/Property
-----------------------------------------------------------------
METHOD 1 MUST be "REQUEST
VEVENT 1+ All components MUST have the same
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
UID 1
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be
DTEND 0 or 1 if present DURATION MUST NOT be
DURATION 0 or 1 if present DTEND MUST NOT be
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
recurring calendar component. Otherwise
MUST NOT be present
RELATED-TO 0+
REQUEST-STATUS 0+
RESOURCES 0 or 1 This property MAY contain a list of
RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers
a
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
The "REQUEST" method may be used to reschedule an event.
rescheduled event involves a change to the existing event in terms
its time or recurrence intervals and possibly the location
description. If the recipient CUA of a "REQUEST" method finds
the "UID" property value already exists on the calendar, but that
"SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method
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
The "REQUEST" method may be used to update or reconfirm an event.
update to an existing event does not involve changes to the time
recurrence intervals, and might not involve a change to the
or description for the event. If the recipient CUA of a "REQUEST
method finds that the "UID" property value already exists on
calendar and that the "SEQUENCE" property value in the "REQUEST"
the same as the value for the existing event, then the "REQUEST
method describes an update of the event details, but no
of the event
The update "REQUEST" method is the appropriate response to
"REFRESH" method sent from an "Attendee" to the "Organizer" of
event
The "Organizer" of an event may also send unsolicited "REQUEST
methods. The unsolicited "REQUEST" methods may be used to update
details of the event without rescheduling it, to update
"partstat" parameter of "Attendees", or to reconfirm the event
3.2.2.3 Delegating an Event to another
Some calendar and scheduling systems allow "Attendees" to
their presence at an event to another calendar user. ITIP
this concept using the following workflow. Any "Attendee"
delegate their right to participate in a calendar VEVENT to
CU. The implication is that the delegate participates in lieu of
original "Attendee"; NOT in addition to the "Attendee". The
MUST notify the "Organizer" of this action using the steps
below. Implementations may support or restrict delegation as
see fit. For instance, some implementations may restrict a
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
"Delegate". The "REQUEST" method MUST include an "ATTENDEE"
with the calendar address of the "Delegate". The "Delegator"
also send a "REPLY" method to the "Organizer" with the "Delegator's
"ATTENDEE" property "partstat" parameter value set to "delegated".
addition, the "delegated-to" parameter MUST be included with
calendar address of the "Delegate".
In response to the request, the "Delegate" MUST send a "REPLY"
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
though they will not be attending. This is accomplished by
"Delegator" setting their "role" attribute to " NON-PARTICIPANT"
the "REPLY" to the "Organizer
3.2.2.4 Changing the
The situation may arise where the "Organizer" of a VEVENT is
longer able to perform the "Organizer" role and abdicates
passing on the "Organizer" role to someone else. When this occurs
"Attendees" of the VEVENT may use out-of-band mechanisms
communicate the situation and agree upon a new "Organizer". The
"Organizer" should then send out a new "REQUEST" with a
version of the VEVENT in which the "SEQUENCE" number has
incremented and value of the "ORGANIZER" property has been changed
the calendar address of the new "Organizer".
3.2.2.5 Sending on Behalf of the
There are a number of scenarios that support the need for a
user to act on behalf of the "Organizer" without explicit
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
another. Using the "sent-by" parameter, a calendar user could send
updated "VEVENT" REQUEST. In the case where one CU sends on behalf
another CU, the "Attendee" responses are still directed back
the CU designated as "Organizer".
3.2.2.6 Forwarding to An Uninvited
An "Attendee" invited to an event may invite another uninvited CU
the event. The invited "Attendee" accomplishes this by forwarding
original "REQUEST" method to the uninvited CU. The "Organizer
decides whether or not the uninvited CU is added to the
Silverberg, et. al. Standards Track [Page 20]
RFC 2446 iTIP November 1998
list. If the "Organizer" decides not to add the uninvited CU
further action is required, however the "Organizer" MAY send
uninvited CU a "CANCEL" message. If the "Organizer" decides to
an uninvited CU, a new "ATTENDEE" property is added for the
CU with its property parameters set as the "Organizer"
appropriate. When forwarding a "REQUEST" to another CU,
forwarding "Attendee" MUST NOT make changes to the VEVENT
set
3.2.2.7 Updating Attendee
The "Organizer" of an event may also request updated status from
or more "Attendees. The "Organizer" sends a "REQUEST" method to
"Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter.
"SEQUENCE" property for the event is not changed from its
value. A recipient will determine that the only change in
"REQUEST" is that their "RSVP" property parameter indicates a
for updated status. The recipient SHOULD respond with a "REPLY
method indicating their current status with respect to the "REQUEST".
3.2.3
The "REPLY" method in a "VEVENT" calendar component is used
respond (e.g., accept or decline) to a "REQUEST" or to reply to
delegation "REQUEST". When used to provide a delegation response,
"Delegator" SHOULD include the calendar address of the "Delegate"
the "delegated-to" property parameter of the "Delegator's" "ATTENDEE
property. The "Delegate" SHOULD include the calendar address of
"Delegator" on the "delegated-from" property parameter of
"Delegate's" "ATTENDEE" property
The "REPLY" method may also be used to respond to an
"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
not in the original "REQUEST". For example, a "REPLY" may be
from a "Delegate" to an event. In addition, the "REPLY" method may
received from an unknown CU (a "Party Crasher"). This
"Attendee" may be accepted, or the "Organizer" may cancel the
for the uninvited "Attendee" by sending a "CANCEL" method to
uninvited "Attendee".
An "Attendee" can include a message to the "Organizer" using
"COMMENT" property. For example, if the user indicates
acceptance and wants to let the "Organizer" know why, the reason
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
another. Like the scenario enumerated above for the "Organizer",
"Attendees" may have another CU respond on their behalf. This is
using the "sent-by" parameter
The optional properties listed in the table below (those listed
"0+" or "0 or 1") MUST NOT be changed from those of the
request. If property changes are desired the COUNTER message must
used
This method type is an iCalendar object that conforms to
following property constraints
Component/Property
------------------- ----------------------------------------------
METHOD 1 MUST be "REPLY
VEVENT 1+ All components MUST have the same
ATTENDEE 1 MUST be the address of the
replying
DTSTAMP 1
ORGANIZER 1
RECURRENCE-ID 0 or 1 only if referring to an instance of
recurring calendar component.
it must NOT be present
UID 1 MUST be the UID of the original
SEQUENCE 0 or 1 MUST if non-zero, MUST be the
number of the original REQUEST. MAY
present if 0.
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of
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
DTSTART 0 or 1
DURATION 0 or 1 if present DTEND MUST NOT be
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
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
to a
X-COMPONENT 0+
VALARM 0
VFREEBUSY 0
VJOURNAL 0
VTODO 0
3.2.4
The "ADD" method in a "VEVENT" calendar component is used to add
or more instances to an existing "VEVENT". Unlike the "REQUEST
method, when using issuing an "ADD" method, the "Organizer" does
send the full "VEVENT" description; only the new instance(s).
"ADD" method is especially useful if there are instance-
properties to be preserved in a recurring "VEVENT". For instance,
"Organizer" may have originally scheduled a weekly Thursday meeting
At some point, several instances changed. Location or start time
have changed, or some instances may have unique "DESCRIPTION
properties. The "ADD" method allows the "Organizer" to add
instances to an existing event using a single ITIP message
redefining the entire recurring pattern
The "UID" must be that of the existing event. If the "UID"
value in the "ADD" is not found on the recipient's calendar, then
recipient SHOULD send a "REFRESH" to the "Organizer" in order to
updated with the latest version of the "VEVENT". If an "Attendee
implementation does not support the "ADD" method it should
with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
This method type is an iCalendar object that conforms to
following property constraints
Silverberg, et. al. Standards Track [Page 23]
RFC 2446 iTIP November 1998
Component/Property
------------------- ----------------------------------------------
METHOD 1 MUST be "ADD
VEVENT 1
DTSTAMP 1
DTSTART 1
ORGANIZER 1
SEQUENCE 1 MUST be greater than 0
SUMMARY 1 Can be
UID 1 MUST match that of the original
ATTACH 0+
ATTENDEE 0+
CATEGORIES 0 or 1 This property MAY contain a list of
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be
DTEND 0 or 1 if present DURATION MUST NOT be
DURATION 0 or 1 if present DTEND MUST NOT be
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
RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/
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
a
X-COMPONENT 0+
VFREEBUSY 0
VTODO 0
VJOURNAL 0
Silverberg, et. al. Standards Track [Page 24]
RFC 2446 iTIP November 1998
3.2.5
The "CANCEL" method in a "VEVENT" calendar component is used to
a cancellation notice of an existing event request to
"Attendees". The message is sent by the "Organizer" of the event.
a recurring event, either the whole event or instances of an
may be cancelled. To cancel the complete range of recurring event
the "UID" property value for the event MUST be specified and
"RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method.
order to cancel an individual instance of the event,
"RECURRENCE-ID" property value for the event MUST be specified in
"CANCEL" method
There are two options for canceling a sequence of instances of
recurring "VEVENT" calendar component
(a) the "RECURRENCE-ID" property for an instance in the sequence
be specified with the "RANGE" property parameter value
THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of
specified "VEVENT" calendar component and all instances
(or after);
(b) individual recurrence instances may be cancelled by
multiple "RECURRENCE-ID" properties corresponding to
instances to be cancelled
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST
incremented
This method type is an iCalendar object that conforms to
following property constraints
Component/Property
------------------- ----------------------------------------------
METHOD 1 MUST be "CANCEL
VEVENT 1+ All must have the same
ATTENDEE 0+ MUST include all "Attendees" being
the event. MUST include all "Attendees"
the entire event is cancelled
DTSTAMP 1
ORGANIZER 1
SEQUENCE 1
UID 1 MUST be the UID of the original
COMMENT 0 or 1
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of
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
DTSTART 0 or 1
DURATION 0 or 1 if present DTEND MUST NOT be
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
more or more recurring instances
Otherwise it MUST NOT be
RELATED-TO 0+
RESOURCES 0 or 1
RRULE 0+
STATUS 0 or 1 MUST be set to CANCELLED. If
specific "Attendees" then MUST NOT
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
a
X-COMPONENT 0+
VTODO 0
VJOURNAL 0
VFREEBUSY 0
VALARM 0
3.2.6
The "REFRESH" method in a "VEVENT" calendar component is used
"Attendees" of an existing event to request an updated
from the event "Organizer". The "REFRESH" method must specify
"UID" property of the event to update. A recurrence instance of
event may be requested by specifying the "RECURRENCE-ID"
corresponding to the associated event. The "Organizer" responds
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
following property constraints
Component/Property
------------------- ----------------------------------------------
METHOD 1 MUST be "REFRESH
VEVENT 1
ATTENDEE 1 MUST be the address of
DTSTAMP 1
ORGANIZER 1
UID 1 MUST be the UID associated with
COMMENT 0 or 1
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of
recurring calendar component.
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
The "COUNTER" method for a "VEVENT" calendar component is used by
"Attendee" of an existing event to submit to the "Organizer"
counter proposal to the event description. The "Attendee" sends
message to the "Organizer" of the event
The counter proposal is an iCalendar object consisting of a
calendar component describing the complete description of
alternate event
The "Organizer" rejects the counter proposal by sending
"Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer"
the counter proposal by rescheduling the event as described
section 3.2.2.1 Rescheduling an Event
This method type is an iCalendar object that conforms to
following property constraints
Component/Property
------------------- ----------------------------------------------
METHOD 1 MUST be "COUNTER
VEVENT 1
DTSTAMP 1
DTSTART 1
ORGANIZER 1 MUST be the "Organizer" of the
SEQUENCE 1 MUST be present if value is greater than 0,
MAY be present if 0
SUMMARY 1 Can be
UID 1 MUST be the UID associated with the
being
ATTACH 0+
ATTENDEE 0+ Can also be used to propose
"Attendees
CATEGORIES 0 or 1 This property may contain a list of
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
DURATION 0 or 1 if present DTEND MUST NOT be
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
recurring calendar component. Otherwise
MUST NOT be present
RELATED-TO 0+
REQUEST-STATUS 0+
RESOURCES 0 or 1 This property may contain a list of
RRULE 0+
STATUS 0 or 1 Value must be one of CONFIRMED/TENATIVE
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers
a
X-COMPONENT 0+
VTODO 0
VJOURNAL 0
VFREEBUSY 0
3.2.8
The "DECLINECOUNTER" method in a "VEVENT" calendar component is
by the "Organizer" of an event to reject a counter proposal
by an "Attendee". The "Organizer" must send the "DECLINECOUNTER
message to the "Attendee" that sent the "COUNTER" method to
"Organizer".
This method type is an iCalendar object that conforms to
following property constraints
Silverberg, et. al. Standards Track [Page 29]
RFC 2446 iTIP November 1998
Component/Property
------------------- ----------------------------------------------
METHOD 1 MUST be "DECLINECOUNTER
VEVENT 1
DTSTAMP 1
ORGANIZER 1
UID 1 MUST, same UID specified in
REQUEST and subsequent
COMMENT 0 or 1
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of
recurring calendar component. Otherwise
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
This section defines the property set for the methods that
applicable to the "VFREEBUSY" calendar component. Each of the
is defined using a restriction table
This document only addresses the transfer of busy time information
Applications desiring free time information MUST infer this
available busy time information
The busy time information within the iCalendar object MAY be
into more than one "VFREEBUSY" calendar component. This
allows busy time periods to be grouped according to some
periodicity, such as a calendar week, month, or year. In this case
each "VFREEBUSY" calendar component</