| | 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. |
|==============+============================+=========================|
| 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.
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
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.
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.
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
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
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".
+---------------------------------------------------------------------+
| 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
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
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".
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
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.
+---------------------------------------------------------------------+
| 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 | | |
+---------------------------------------------------------------------+
"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
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.
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.
+--------------------------------------------------------------------+
| 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
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
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
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.
+--------------------------------------------------------------------+
| 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
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
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
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VEVENT
UID:guid-1@host1.com