RFC 2446
iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
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.
+================+==================================================+ | 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
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+
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:
(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+
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 |
| | 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. | |==============+============================+=========================|
| 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.
(page 78 continued on part 4)
