home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_a_c
/
draft-ietf-calsch-itip-part1-00.txt
< prev
next >
Wrap
Text File
|
1997-07-22
|
166KB
|
6,117 lines
Network Working Group Steve Silverberg, Microsoft
INTERNET-DRAFT Steve Mansour, Netscape
<draft-ietf-calsch-itip-part1-00.txt> Frank Dawson, Lotus
Expires in six months from 18 July 1997 Ross Hopson, ON Technologies
iCalendar Transport-Independent Interoperability Protocol
(iTIP) Part One:
Scheduling Events and BusyTime
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or made obsolete by other
documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or
"work in progress".
To learn the current status of any Internet-Draft, please check the 1id-
abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Distribution of this document is unlimited.
Abstract
This set of documents, collectively called the iCalendar Transport-
independent Interoperability Protocol, or iTIP, defines a transport-
independent message protocol to allow for searching busy time and the
scheduling of events, to-dos, or journal entries on different
calendaring and scheduling systems. These documents are based on earlier
work documented in the iCalendar format. Because iCalendar dealt mainly
with the format of calendaring information and said so little about the
method for conveying scheduling semantics, these documents are largely
orthogonal to (rather than a revision of) iCalendar.
Part 1 specifies the messages for allowing searching busy time
information and for scheduling events. Part 2 defines the messages for
scheduling to-dos, or action items. Part 3 defines the messages for
scheduling journal entries. This document set is intended to convey
calendaring and scheduling semantics between different applications
independent of transport. This document is also being offered as a
specification for demonstrating industry-wide, calendaring and
scheduling interoperability. The protocol defined by this document is
applicable for conveying calendaring and scheduling information across
any reliable transport. This format is useful for both client-to-server
communication, server-to-server communication, and client-to-client,
peer communication (e.g., PDA synchronization with a PIM).
The breadth of this document is limited to exchanging calendar
information only. It does not address issues related to tasks or journal
Silverberg/Mansour/Dawson/Hopson 1 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
entries. Instead, the document outlines a model for calendar exchange
that defines both static and dynamic event objects. Static event objects
are used to transmit events from one entity to another without the
expectation of continuity or referential integrity with the original
item. Dynamic event objects are a superset of static event objects and
will gracefully degrade to their static counterparts for clients that
only support static appointment objects.
Silverberg/Mansour/Dawson/Hopson 2 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Table of Contents:
1 INTRODUCTION.........................................................5
1.1 ITIP SCHEDULING TRANSACTIONS .....................................5
2 INTEROPERABILITY MODELS..............................................6
2.1 APPLICATION PROTOCOL .............................................6
2.1.1 Scheduling Transaction State ..................................7
2.2 ADVANCED CALENDARING CONCEPTS ....................................8
2.3 CALENDAR ROLES ...................................................8
2.4 DELEGATION .......................................................9
3 APPLICATION PROTOCOL ELEMENTS.......................................11
3.1 ITIP MESSAGE CONFORMANCE ........................................12
3.1.1 Restrictions on DTSTART and DTEND ............................12
3.2 SUMMARY OF APPLICATION PROTOCOL ELEMENTS ........................12
3.2.1 EVENT-PUBLISH ................................................12
3.2.2 EVENT-REQUEST ................................................16
3.2.3 EVENT-REPLY ..................................................20
3.2.4 EVENT-CANCEL .................................................24
3.2.5 EVENT-REQUEST for Replacing an Event .........................27
3.2.6 EVENT-COUNTER ................................................31
3.2.7 EVENT-DECLINECOUNTER .........................................35
3.2.8 EVENT-REQUEST for Delegation .................................38
3.2.9 BUSY-REQUEST .................................................46
3.2.10 BUSY-REPLY ..................................................50
3.2.11 EVENT-RESEND ................................................54
3.3 STATUS REPLIES ..................................................57
3.4 IMPLEMENTATION CONSIDERATIONS ...................................59
3.4.1 Working With Recurrence Instances ............................59
3.4.2 When To Resend An Event ......................................60
3.4.3 Timezones ....................................................64
3.4.4 Alarms .......................................................64
3.4.5 SUMMARY Property .............................................64
3.4.6 X-Tokens .....................................................64
4 EXAMPLES............................................................65
4.1 PUBLISHED EVENT EXAMPLES ........................................65
4.1.1 A Minimal Published Event ....................................66
4.1.2 Changing A Published Event ...................................66
4.1.3 Canceling A Published Event ..................................67
4.1.4 A Rich Published Event .......................................67
4.2 GROUP EVENT EXAMPLES ............................................68
4.2.1 A Group Event Request ........................................69
4.2.2 Reply To A Group Event Request ...............................70
4.2.3 Update An Event ..............................................70
4.2.4 Countering an Event Proposal .................................71
4.2.5 Delegate An Event ............................................73
4.2.6 Delegate Accepts the Meeting .................................75
Silverberg/Mansour/Dawson/Hopson 3 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
4.2.7 Delegate Declines the Meeting ................................76
4.2.8 Cancel A Group Event .........................................77
4.3 BUSY TIME EXAMPLES ..............................................78
4.3.1 Request Busy Time ............................................78
4.3.2 Reply To A Busy Time Request .................................79
4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ..........................79
4.4.1 A Recurring Event Spanning Timezones .........................79
4.4.2 Modify A Recurring Instance ..................................81
4.4.3 Cancel A Recurring Instance ..................................82
4.4.4 Cancel An Exception ..........................................82
4.4.5 Cancel Recurring Event .......................................83
4.4.6 Change All Future Instances ..................................83
4.4.7 Add A New Instance To A Recurring Event ......................83
4.4.8 Counter An Instance Of A Recurring Event .....................84
4.4.9 Error Reply To An EVENT-REQUEST ..............................85
5 APPLICATION PROTOCOL FALLBACKS......................................86
5.1 PROFILES ........................................................86
5.2 CALENDAR COMPONENTS .............................................86
5.3 CALENDAR PROPERTIES .............................................87
5.4 COMPONENT PROPERTIES ............................................87
5.5 LATENCY ISSUES ..................................................90
5.5.1 Cancelation of an Unknown Event. .............................90
5.5.2 Unexpected Reply from an Unknown Delegate ....................90
5.6 SEQUENCE NUMBER .................................................91
6 SECURITY CONSIDERATIONS.............................................92
7 ACKNOWLEDGMENTS.....................................................93
8 BIBLIOGRAPHY........................................................94
9 AUTHORS ADDRESSES...................................................95
APPENDIX A. TRANSPORT PROTOCOL CONSIDERATIONS.........................96
Silverberg/Mansour/Dawson/Hopson 4 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
1 Introduction
The purpose of this document set is to define the format of iCalendar
Objects and how the iCalendar Objects are conveyed between Calendar User
Agents (CUA) and Calendar Services (CS). This involves the definition of
a protocol that uses the iCalendar Object as the basis for a collection
of messages that are transmitted from one calendaring system to another.
The protocol is transport independent but can be bound to either a real-
time transport or a store-and-forward transport such as e-mail.
This initial document specifies the messages for allowing searching for
busy time information and for scheduling events. The second document
defines the messages for scheduling to-dos, or action items. The third
document defines the messages for scheduling journal entries.
Implemented as a whole, this document set will allow different
calendaring and scheduling domains to interoperate; allowing for the
search for available busy time information and scheduling events, to-
dos, or daily journal entries.
1.1 iTIP Scheduling Transactions
The profiles described in this document may be considered additions to
[ICAL] and are designed specifically for the exchange of calendaring
information between scheduling applications.
Event Publication
. Publish an event
. Change a published event
. Cancel a published event
Group Events
. Request an event to be scheduled on one or more recipients calendars;
. Reply to an existing event request to confirm, decline, conform as
tentative, or delegate the request;
. Allow a recipient of an event to assign delegates to attend a
meeting;
. Allow the organizer of an event to cancel the event;
. Allow the organizer of an event to replace the original event
definition;
. Allow an attendee the ability to negotiate event property changes
. Allow attendee to request and receive meeting updates
Free/Busy Time
. Request busy time time data from one or more recipients;
. Reply to a busy time request with busy time data;
Recurring Events and Timezones
. Support scheduling an event between individuals in different time
zones;
. Support for time zones;
. Support for DST rules;
. Create a recurring meeting request with exception dates
Silverberg/Mansour/Dawson/Hopson 5 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
2 Interoperability Models
There are two distinct protocols relevant to interoperability: an
Application Protocol and a Transport Protocol. The Application Protocol
defines the content of the iCalendar Objects sent between sender and
receiver to accomplish the Scheduling Transactions listed in section
1.1. The Transport Protocol defines how the iCalendar Objects are sent
between the sender and receiver. This document focuses on the
Application Protocol. Some considerations for Transport Protocol
documents are listed in Appendix A.
The connection between Sender and Receiver in the diagram below refers
to the Application Protocol. In particular, the iCalendar Objects passed
from the Sender to the Receiver which conform to those presented in
Section 2.1.
+----------+ +----------+
| | iTIP | |
| Sender |<-------------------->| Receiver |
| | | |
+----------+ +----------+
There are several variations of this diagram in which the Sender and
Receiver take on various roles of CUA or CS. These variants are
detailed in the Model document [ICMS]
The architecture of iTIP is depicted in the diagram below. An
application written to this specification can work with bindings for the
store-and-forward transport, the real time transport, or both. Also note
that iTIP could be bound to other transports. If a capability is not
available on a particular transport binding, iTIP provides a mechanism
for indicating so.
+------------------------------------------+
| iCalendar |
+------------------------------------------+
| iTIP |
+------------------------------------------+
|Real-time | Store-and-Fwd | Other |
|Transport | Transport | Transports... |
+------------------------------------------+
2.1 Application Protocol
The model for the application protocol is centered around the organizer
of the event. That is, the organizer of a request sends it out to one or
more invitees. The attendees reply back to the organizer. The organizer
maintains the status of the event.
The data sources for the application protocol are the Calendar Users
[ICMS]. Examples of these users are the organizer and attendees of an
Silverberg/Mansour/Dawson/Hopson 6 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
iCalendar event. The data objects are the iCalendar Objects that are
exchanged between Calendar Users.
2.1.1 Scheduling Transaction State
The state of the event scheduling transaction is described by the STATUS
and ATTENDEE properties in the event calendar component.
The state of an event request changes from the time it is initially
assigned, to when the attendees reply to the request, to when each of
the attendees complete the event. When an organizer sends out the event
request its state with respect to the attendees is NEEDS-ACTION. If the
attendee accepts the assignment, then the status is changed to ACCEPTED.
If the attendee rejects the assignment, then the status is changed to
DECLINED. These changes in the attendee status for the event are
effected by the attendee sending the organizer an EVENT-REPLY message.
The status of the event is reflected by the STATUS property. The event
STATUS property is controlled by the organizer. There is no default
status. The organizer can either set the event status to TENTATIVE or
CONFIRMED. The organizer can also set the status to CANCELLED by sending
an EVENT-CANCEL message to the attendees.
The states of the protocol are contained in the iCalendar Object. Due to
the individual nature of a scheduling transaction, the state may be
different for each Calendar User. The diagram below describes the
various state changes.
+=======================+=====================+===================+
| Organizer | Attendee | Delegate |
+=======================+=====================+===================+
| |
| EVENT-PUBLISH ------------------------> |
| Status=CONFIRMED |
| |
+=======================+=====================+===================+
| |
| EVENT-REQUEST ------------------------> |
| Status=CONFIRMED | TENTATIVE |
| Attendee Status=NEEDS-ACTION |
| |
| <--------------------------------EVENT-REPLY |
| Status=As specified in the EVENT-REQUEST message |
| Attendee Status=ACCEPTED | DECLINED | TENTATIVE |
| |
+=======================+=====================+===================+
| |
| EVENT-REQUEST ------------------------> |
| Status=CONFIRMED | TENTATIVE |
| Attendee Status=NEEDS-ACTION |
| |
| <--------------------------------EVENT-REPLY |
| Attendee Status=DELEGATED |
| |
Silverberg/Mansour/Dawson/Hopson 7 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
| EVENT-DELEGATE----------------> |
| Attendee Status=NEEDS-ACTION |
| |
| <------------------------------------------------EVENT-REPLY |
| <----------------------EVENT-REPLY |
| Attendee Status=ACCEPTED | DECLINED | TENTATIVE |
| |
+=======================+=====================+===================+
| |
| EVENT-CANCEL ------------------------> |
| Status=CANCELLED |
| Attendee Status=As specified in the EVENT-REPLY |
| |
+=======================+=====================+===================+
| |
| EVENT-REQUEST ------------------------> |
| (A rescheduled or redefined event) |
| Status=CONFIRMED | TENTATIVE |
| Attendee Status=As defined in previous EVENT-REPLY |
| message for this event |
| |
+=======================+=====================+===================+
2.2 Advanced Calendaring Concepts
The calendaring and scheduling capability defined by this document is
based on the exchange of messages between the organizer of an event and
one or more Calendar User Agents (CUA). The message protocol emulates a
"request" and "reply" form of communications. However, there is a class
of actions that are non-interactive and are more consistent with
publishing. These include the publishing of static events.
The message format is designed to be used equally well with a MIME
electronic messaging transport, real time protocols, and other Internet
and non-Internet message transports.
This message-based protocol is based on "request" messages sent from an
originator and conveyed to one or more recipients. A recipient of a
"request" message may "reply" to the request, in order to update their
status and may also return transaction/request status information. The
protocol also supports the ability for the originator of an event to
change or cancel the original request. The elements of the protocol also
include the notion of user roles.
2.3 Calendar Roles
Roles are a behavior or set of activities performed by particular groups
of users or agents at a given state of the application. This
specification describes 4 roles that determine a range of actions and
responsibilities specific to each role. When scheduling an appointment
with 1 or more individuals, there are 2 roles: Organizer and attendee.
The organizer sends the meeting request and receives responses from
attendees. The organizer is implicitly, the owner of the meeting.
Silverberg/Mansour/Dawson/Hopson 8 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
However, there are scenarios where the owner has a delegate who acts on
the owner's behalf, as is the case when an assistant books a meeting. In
this scenario the organizer and the owner are different individuals yet
the organizer is still responsible for sending and receiving the
requests and managing the calendar contains this event. A delegate role
is created when an attendee delegates an event or task to another CUA.
Role Description
Organi The organizer is the user that sends and manages
zer the event _ meaning responses are directed to the
organizer. In most cases the organizer is also the
owner, but in cases where the owner delegates
organizer responsibility to a delegate the
organizer becomes a proxy for the owner. The
organizer in this case would place the meeting on
the calendar of the owner.
Owner The owner usually controls direct manipulation of
the event. The owner is usually the organizer but
in some cases a delegate or proxy will act on
behalf of the owner and organize the meeting and
logistics. The organizer can make unilateral
changes to the event while the attendees can only
act through the organizer.
Attend Attendees are those recipients who are invited to
ees the meeting. When an attendee responds the status
property is set to either accept, decline or
tentative. A delegate may respond on behalf of an
attendee.
Delega A delegate is a proxy that acts on behalf of an
te attendee.
2.4 Delegation
The calendaring and scheduling model identifies three types of
delegation.
1.
When an owner delegates calendar management to an organizer who
acts on the owner's behalf
2.
When an attendee grants delegate status to another calendar user
Silverberg/Mansour/Dawson/Hopson 9 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
who responds to requests on behalf of the attendee.
3.
When an attendee delegates an event request to another calendar
user who then becomes an attendee.
This document discusses only item 3. Items 1 and 2 are described in the
calendar access protocol (as described in [ICMS]).
When an attendee delegates an Event-Request they are required to notify
the organizer using an Event-Reply. This contains the necessary
information for the organizer to discern that the request was delegated
and the identity of the delegate. Section 3.2.8 describes the delegation
process in detail.
Silverberg/Mansour/Dawson/Hopson 10 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
3 Application Protocol Elements
Messages are the on-the-wire MIME entities that contain calendaring
information. The particular type of [ICAL] message is referred to as the
profile type. Each profile type is identified by a profile property
specified as part of the Text/Calendar content type. The following
describes the various [ICAL] Profile Types supported in this
specification.
Profile Type Description
EVENT-PUBLISH Post notification of an event. Used
primarily as a method of advertising the
existence of an event.
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 EVENT-REQUEST
can degrade the event to view it as an
EVENT-PUBLISH.
EVENT-REPLY Reply to an event request. This includes
"Accept", "Tentative", "Decline" and
"Delegate".
EVENT-CANCEL Cancel an existing event request.
BUSY-REQUEST Request busy time data
BUSY-REPLY Reply to a free/busy time request
EVENT-COUNTER Counter EVENT-REQUEST with alternative
properties
EVENT- Decline counter-request by attendee
DECLINECOUNTER
EVENT-RESEND A request sent to an event organizer
asking for the latest version of an event
Silverberg/Mansour/Dawson/Hopson 11 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
to be resent to the requester.
Each profile type has an associated collection of properties and
methods. Some properties are required and others are optional This
specification is also designed with the notion that some calendaring
clients will be capable of reading and posting events (where posting
means to local calendar). Therefore, profiles such as EVENT-REQUEST will
contain an exact superset of the EVENT-PUBLISH property set such that a
client that supported EVENT-PUBLISH could still read an event request.
3.1 ITIP Message Conformance
An implementation conforming to iTIP must enforce the conventions
described in the sections below. These conventions have been made to
improve interoperability. As a side benefit, they tend to simplify
implementation.
3.1.1 Restrictions on DTSTART and DTEND
DTStart must always be specified. Events containing DTEnd without a
DTStart are not allowed. If the end time is known, the DTEnd parameter
should be specified. The duration cannot be specified in conjunction
with DTStart.
3.2 Summary of Application Protocol Elements
This section outlines the complete property set for each profile type,
indicating the required (designated by the word Required), optional
(designed by the words Not Required) and excluded (designated by the
word Excluded) properties.
3.2.1 EVENT-PUBLISH
The EVENT-PUBLISH is somewhat unique in this document in that it has no
interactivity associated with it. Instead, it is simply an event that
can be added by a calendar user agent to a calendar as a static event.
It requires and accepts no responses to the organizer. Its expected
usage is for encapsulating an arbitrary event as an iCalendar object.
EVENT-PUBLISH
Calendar Properties
GEO
Not Required
Silverberg/Mansour/Dawson/Hopson 12 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required, Value must be "EVENT-
PUBLISH"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
COMMENT
Not Required
CREATED
Not Required
DAYLIGHT
Not Required
DTSTART
Required
DTEND
Not Required
RDATE
Not Required, Either RDATE or RRULE
may be specified, but not both.
RRULE
Not Required, Either RDATE or RRULE
may be specified, but not both.
TZNAME
Not Required
TZOFFSET
Required
TZTRANS
Not Required
Event Component Properties
Silverberg/Mansour/Dawson/Hopson 13 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
ATTACH
Not Required
ATTENDEE
Not Required
CATEGORIES
Not Required
CLASS
Not Required
CREATED
Not Required
COMPLETED
Excluded
DESCRIPTION
Required, Value may be NULL text.
DUE
Excluded
DURATION
Excluded
DTEND
Not Required
DTSAMP
Required
DTSTART
Required
EXDATE
Not Required
EXRULE
Not Required
LAST-MODIFIED
Not Required
LOCATION
Not Required
PRIORITY
Not Required
Silverberg/Mansour/Dawson/Hopson 14 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
RELATED-TO
Not Required
REQUEST-STATUS
Excluded
RDATE
Not Required, See issues list.
RRULE
Not Required, See issues list.
RESOURCES
Not Required
RESPONSE-SEQUENCE
Excluded
SEQUENCE
Required, if not 0
STATUS
Excluded
SUMMARY
Not Required, May be NULL text.
TRANSP
Excluded
URL
Not Required
UID
Required
Alarm Component Properties
ATTACH
Not Required
CATEGORIES
Required, If an alarm is specified
CREATED
Not Required
DESCRIPTION
Not Required
DTSTART
Required, If an alarm is specified
Silverberg/Mansour/Dawson/Hopson 15 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
DURATION
Required, If an alarm is specified
LAST-MODIFIED
Not Required
RELATED-TO
Not Required
REPEAT
Required, If an alarm is specified
SUMMARY
Not Required
URL
Not Required
Non-standard Properties
Excluded-token
Not Required, but recipient may
choose to ignore those non-standard
properties, specified as Not
Required.
3.2.2 EVENT-REQUEST
The EVENT-REQUEST is used to both describe an event and invite potential
attendees. It uses the ICAL property set to describe the meeting in
terms of date/time, location, recurrence, attendees etc. When an EVENT-
REQUEST is received by a user or agent it should be responded to with an
event reply. The table below describes the both the required and
complete property set that make up an EVENT-REQUEST.
EVENT-REQUEST
Calendar Properties
GEO
Not Required
PRODID
Required
VERSION
Value must be "2.0".
Silverberg/Mansour/Dawson/Hopson 16 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
PROFILE
Required,"EVENT-REQUEST"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
COMMENT
Not Required
CREATED
Not Required
DAYLIGHT
Not Required
DTSTART
Required
DTEND
Not Required
RDATE
Not Required, Either RDATE or
RRULE may be specified, but not
both.
RRULE
Not Required, Either RDATE or
RRULE may be specified, but not
both.
TZNAME
Not Required
TZOFFSET
Required
TZTRANS
Not Required
Event Component Properties
ATTACH
Not Required
Silverberg/Mansour/Dawson/Hopson 17 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
ATTENDEE
Required, Value is an RFC822
mailbox address for C&S
capability. STATUS parameter is
either absent or has value "NEEDS
ACTION".
CATEGORIES
Not Required
CLASS
Not Required
CREATED
Not Required
COMPLETED
Excluded
DESCRIPTION
Required, Value may be NULL text.
DUE
Excluded
DURATION
Excluded
DTEND
Not Required, Must be a date/time
after DTSTART. May span date
boundary.
DTSTAMP
Required
DTSTART
Required
EXDATE
Not Required, See issues list.
EXRULE
Not Required, See issues list.
LAST-MODIFIED
Not Required
LOCATION
Not Required
Silverberg/Mansour/Dawson/Hopson 18 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
PRIORITY
Not Required
RELATED-TO
Not Required
REQUEST-STATUS
Excluded
RDATE
Not Required, See issues list.
RRULE
Not Required, See issues list.
RESOURCES
Not Required
RESPONSE-SEQUENCE
Excluded
SEQUENCE
Required, If not zero
STATUS
Not Required, Value only one of
TENTATIVE | CONFIRMED. This
property is used by the organizer
to indicate the consensus for the
meeting, not a status on any of
the attendees.
SUMMARY
Not Required, May be NULL text.
TRANSP
Excluded
URL
Not Required
UID
Required, Must be maintained by
the recipients.
Alarm Component Properties
ATTACH
Not Required
Silverberg/Mansour/Dawson/Hopson 19 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
CATEGORIES
Required, If an alarm is
specified
CREATED
Not Required
DESCRIPTION
Not Required
DTSTART
Required, If an alarm is
specified
DURATION
Required, If an alarm is
specified
LAST-MODIFIED
Not Required
RELATED-TO
Not Required
REPEAT
Required, If an alarm is
specified
SUMMARY
Not Required
URL
Not Required
Non-standard Properties
Excluded-token
Not Required, but recipient may
choose to ignore those non-
standard properties, specified as
Not Required.
3.2.3 EVENT-REPLY
The Event-Reply is used to RSVP and to Delegate.
EVENT-REPLY
Silverberg/Mansour/Dawson/Hopson 20 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Calendar Properties
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"EVENT-REPLY"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
Timezone component is excluded
from this message type.
Event Component Properties
ATTACH
Excluded
ATTENDEE
Required, Value is an RFC822
mailbox address for C&S
capability. Must be the address
of the recipient replying.
CATEGORIES
Excluded
CLASS
Excluded
COMMENT
Text value. Provides Required
comment from the attendee to the
organizer about the reply. For
example, "I can't travel this far
for Required meeting."
CREATED
Excluded
COMPLETED
Excluded
Silverberg/Mansour/Dawson/Hopson 21 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
DESCRIPTION
Excluded
DUE
Excluded
DURATION
Excluded
DTEND
Excluded
DTSTAMP
Required
DTSTART
Excluded
EXDATE
Not Required. See issues list.
Specifies the dates that are
exceptions to the status update.
EXRULE
Not Required. See issues list.
Specifies the rule that defines
the exceptions to the status
update.
LAST-MODIFIED
Excluded
LOCATION
Excluded
PRIORITY
Excluded
RELATED-TO
Excluded
REQUEST-STATUS
Any of the values defined in the
table below in section 3.3.
RDATE
Excluded
RRULE
Excluded
Silverberg/Mansour/Dawson/Hopson 22 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
RESOURCES
Excluded
RESPONSE-SEQUENCE
Required, If not zero.
SEQUENCE
Required, If not zero
STATUS
Excluded Status for attendee must
be specified in STATUS parameter
of ATTENDEE property.
SUMMARY
Excluded
TRANSP
Excluded
URL
Excluded
UID
Required, Must be the UID of the
EVENT-REQUEST associate with the
reply.
To-do Component Properties
To-do component is excluded from
this message type.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
Alarm component is excluded from
this message type.
Freebusy Properties
Freebusy component is excluded
from this message type.
Silverberg/Mansour/Dawson/Hopson 23 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Non-Standard Properties
Excluded-token
Not Required. But recipient may
choose to ignore those non-
standard properties, specified as
Not Required.
3.2.4 EVENT-CANCEL
This message type is used to send a cancellation notice of an existing
event request to the attendees. The message is sent by the event OWNER
or ORGANIZER to the recipients of the current event request. The OWNER
and ORGANIZER are ROLE parameter values for the ATTENDEE property.
EVENT-CANCEL
Calendar Properties
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"EVENT-CANCEL"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
Timezone component is excluded
from this message type.
Event Component Properties
ATTACH
Excluded
ATTENDEE
Excluded
Silverberg/Mansour/Dawson/Hopson 24 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
CATEGORIES
Excluded
CLASS
Excluded
CREATED
Excluded
COMMENT
Not Required, Text value.
Provides Required comment from
the organizer to the attendees
concerning the cancellation
notice.
COMPLETED
Excluded
DESCRIPTION
Excluded
DUE
Excluded
DURATION
Excluded
DTEND
Excluded
DTSTAMP
Required
DTSTART
Excluded
EXDATE
Excluded
EXRULE
Excluded
LAST-MODIFIED
Excluded
LOCATION
Excluded
PRIORITY
Excluded
Silverberg/Mansour/Dawson/Hopson 25 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
RELATED-TO
Excluded
REQUEST-STATUS
Excluded
RDATE
Excluded
RRULE
Excluded
RESOURCES
Excluded
RESPONSE-SEQUENCE
Excluded
SEQUENCE
Excluded
STATUS
Not Required. If present, value
must be "CANCELLED"
SUMMARY
Excluded
TRANSP
Excluded
URL
Not Required
UID
Required, Must be the UID of the
original EVENT-REQUEST associated
with the cancellation notice.
To-do Component Properties
To-do component is excluded from
this message type.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Properties
Silverberg/Mansour/Dawson/Hopson 26 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Alarm component is excluded from
this message type.
Freebusy Protperties
Freebusy component is excluded
from this message type.
Non-standard Properties
Excluded-token
Not Required, But recipient may
choose to ignore those non-
standard properties, specified as
optional.
3.2.5 EVENT-REQUEST for Replacing an Event
When an organizer wishes to change an existing event in terms of time,
location, description they may replace an existing meeting by sending a
new request with the same UID and an appropriate response-sequence
number (the number should be non-zero. The receiving client should
correlate the request to an existing appointment and then check the
sequence number to realize this request is actually a replacement for
the existing meeting. Individual "A" sends a meeting request to "B" and
"C". "B" accepts the meeting and "C" declines and includes text in the
comments property proposing a more appropriate time. "A" sends "B" and
"C" another meeting request using the same UID and a sequence number of
3 (e.g., the third revision of the original event). "B" should infer
that the event request message is actually a replacement for the
existing meeting.
Replacing an event request is predicated on using the same UID,
incrementing the sequence number and replacing the salient calendar
properties.
EVENT-REQUEST (replacing an existing meeting)
Calendar Properties
GEO
Not Required
PRODID
Required
Silverberg/Mansour/Dawson/Hopson 27 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
VERSION
Value must be "2.0".
PROFILE
Required,"EVENT-REQUEST"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
COMMENT
Not Required
CREATED
Not Required
DAYLIGHT
Not Required
DTSTAMP
Required
DTSTART
Required
DTEND
Not Required
RDATE
Not Required, Either RDATE or
RRULE may be specified, but not
both.
RRULE
Not Required, Either RDATE or
RRULE may be specified, but not
both.
TZNAME
Not Required
TZOFFSET
Required
TZTRANS
Not Required
Event Component Properties
ATTACH
Not Required, "VALUE=URL" only.
Silverberg/Mansour/Dawson/Hopson 28 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
ATTENDEE
Required, Value is an RFC822
mailbox address for C&S
capability. STATUS parameter is
either absent or has value "NEEDS
ACTION".
CATEGORIES
Not Required
CLASS
Not Required
CREATED
Not Required
COMPLETED
Excluded
DESCRIPTION
Required, Value may be NULL text.
DUE
Excluded
DURATION
Excluded
DTEND
Not Required, Must be a date/time
after DTSTART. May span date
boundary.
DTSTAMP
Required
DTSTART
Required
EXDATE
Not Required, See issues list.
EXRULE
Not Required, See issues list.
LAST-MODIFIED
Not Required
LOCATION
Not Required
Silverberg/Mansour/Dawson/Hopson 29 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
PRIORITY
Not Required
RELATED-TO
Not Required
REQUEST-STATUS
Excluded
RDATE
Not Required, See issues list.
RRULE
Not Required, See issues list.
RESOURCES
Not Required
RESPONSE-SEQUENCE
Excluded
SEQUENCE
Required, if not zero
STATUS
Not Required, Value only one of
TENTATIVE | CONFIRMED. This
property is used by the organizer
to indicate the consensus for the
meeting, not a status on any of
the attendees.
SUMMARY
Not Required, May be NULL text.
TRANSP
Excluded
URL
Not Required
UID
Required, Must match the original
meeting request which this
request replaces
Alarm Component Properties
ATTACH
Not Required
Silverberg/Mansour/Dawson/Hopson 30 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
CATEGORIES
Required, If an alarm is
specified
CREATED
Not Required
DESCRIPTION
Not Required
DTSTART
Required, If an alarm is
specified
DURATION
Required, If an alarm is
specified
LAST-MODIFIED
Not Required
RELATED-TO
Not Required
REPEAT
Required, If an alarm is
specified
SUMMARY
Not Required
URL
Not Required
Non-standard Properties
Excluded-token
Not Required, but recipient may
choose to ignore those non-
standard properties, specified as
Not Required.
3.2.6 EVENT-COUNTER
In the course of scheduling events an attendee may wish to modify event
properties such as time, place, included documents etc. ITIP allows for
a structured negotiation between attendee and organizer through the use
of 2 messages: EVENT-COUNTER and EVENT-DECLINECOUNTER. The attendee uses
an Event-Counter, essentially an Event-Request with the proposed
modifications, to propose changes to the organizer. The organizer
Silverberg/Mansour/Dawson/Hopson 31 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
accepts or rejects some or all of the proposed modifications by either
sending a new Event-Request with an incremented sequence number and the
same UID to all attendees or replying to the attendee with an EVENT-
COUNTERDECLINE. The latter simply informs the attendee that their
counter proposal was rejected. The EVENT-COUNTER message must include a
complete description of the event.
EVENT-COUNTER
Calendar Properties
GEO Not Required
PRODID Required
VERSION A, Value must be "2.0".
PROFILE Required,"EVENT-COUNTER"
PROFILE-VERSION Required, Value must be "1.0".
Timezone Component Properties
CREATED Not Required
DAYLIGHT Not Required
DTSAMP Required
DTSTART Required
DTEND Not Required
RDATE Not Required, Either RDATE or
RRULE may be specified, but not
both.
RRULE Not Required, Either RDATE or
RRULE may be specified, but not
both.
TZNAME Not Required
TZOFFSET Required
TZTRANS Not Required
UID Not Required
Event Component Properties
Silverberg/Mansour/Dawson/Hopson 32 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
ATTACH Not Required, VALUE=URL only.
ATTENDEE Required, Value is an RFC822
mailbox address for C&S
capability. A TYPE=ROOM
parameter value pair supported.
Property can be used to propose
other attendees.
CATEGORIES Not Required
CLASS Not Required
COMMENT Not Required, Text value.
Provides a comment from the
recipient to the originator
about the counter proposal. For
example, "How about my place
instead of yours".
CREATED Required
COMPLETED Excluded
DESCRIPTION A, Value may be NULL text.
DUE Excluded
DURATION Excluded
DTEND Required, Value is of the ISO
8601 complete representation,
basic format of a UTC based
date and time; unless
specifying a loosely coupled
date and time.
DTSTAMP Required
DTSTART Not Required, Value iNot
Required of the INot RequiredO
8601 complete repreNot
Requiredentation, baNot
Requiredic format of a UTC
baNot Requireded date and time;
unleNot RequiredNot Required
Not Requiredpecifying a looNot
Requiredely coupled date and
time.
EXDATE Not Required, See issues list.
Silverberg/Mansour/Dawson/Hopson 33 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
EXRULE Not Required, See issues list.
LAST-MODIFIED Excluded
LOCATION Not Required
RNUM Excluded
PRIORITY Excluded
RELATED-TO Not Required
REQUEST-STATUS Excluded
RDATE Not Required, See issues list.
RRULE Not Required, See issues list.
RESOURCES Not Required
RESPONSE-SEQUENCE Required, If not zero
SEQUENCE Required, If not zero
STATUS Excluded
SUMMARY Not Required, May be NULL text.
TRANSP Excluded
URL Not Required
UID Required, Must be the value of
the UID of the EVENT-REQUEST
associated with the counter
proposal.
To-do Component Properties
To-do component is excluded
from this message type.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Properties
Alarm component is excluded
from this message type.
Silverberg/Mansour/Dawson/Hopson 34 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Freebusy Properties
Freebusy component is excluded
from this message type.
Non-standard Properties
X-token Not Required, But recipient may
choose to ignore those non-
standard properties, specified
as optional.
3.2.7 EVENT-DECLINECOUNTER
This message type is used by the organizer of an event request to
decline a counter proposal. It is sent only to the issuer of the Event-
Counter and requires no further action. Acceptance of a counter proposal
message is accomplished when the ORGANIZER of the original event request
sends an EVENT-REQUEST with the updated event description including the
original UID and an incremented SEQUENCE NUMBER.
EVENT-DECLINECOUNTER
Calendar Properties
GEO Not Required
PRODID Required
VERSION Required, Value must be "2.0".
PROFILE Required,"EVENT-DECLINECOUNTER"
PROFILE-VERSION Required, Value must be "1.0".
Timezone Properties
Timezone component is excluded
from this message type.
Event Component Properties
ATTACH Excluded
Silverberg/Mansour/Dawson/Hopson 35 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
ATTENDEE Not Required, Value is an
RFC822 mailbox address for C&S
capability. Address corresponds
to the originator (i.e.,
ATTENDEE value) of the counter
proposal message.
CATEGORIES Excluded
CLASS Excluded
COMMENT Not Required, Text value.
Provides a comment from the
originator to the recipient
about the decline of the
counter proposal. For example,
"We are unable to change the
meeting time or place".
CREATED Excluded
COMPLETED Excluded
DESCRIPTION Excluded
DUE Excluded
DURATION Excluded
DTEND Excluded
DTSTAMP Required
DTSTART Excluded
EXDATE Excluded
EXRULE Excluded
LAST-MODIFIED Excluded
LOCATION Not Required
PRIORITY Excluded
RELATED-TO Not Required
REQUEST-STATUS Not Required
RDATE Excluded
RRULE Excluded
Silverberg/Mansour/Dawson/Hopson 36 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
RESOURCES Excluded
RESPONSE-SEQUENCE Required
SEQUENCE Required, Must be the same as
that specified in the EVENT-
COUNTER.
STATUS Excluded
SUMMARY Excluded
TRANSP Excluded
URL Excluded
UID Required, Must be the value of
the UID of the original EVENT-
REQUEST referenced in the
counter proposal.
To-do Component Properties
To-do component is excluded
from this message type.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
Alarm component is excluded
from this message type.
Freebusy Properties
Freebusy component is excluded
from this message type.
Non-standard Properties
X-token Not Required, but recipient may
choose to ignore those non-
standard properties, specified
as optional.
Silverberg/Mansour/Dawson/Hopson 37 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
3.2.8 EVENT-REQUEST for Delegation
EVENT-REQUEST messages may be delegated to another individual. The
message is sent by one of the attendees of an existing event request to
some other individual.
The message type MAY only be sent by one of the attendees of an existing
event request. The properties from the original event request MUST be
included in the calendar component to assure that the delegated attendee
has a complete specification of the delegated event. This MAY include a
description that reflects numerous revisions of the original request.
The message must also contain a new ATTENDEE property corresponding to
the individual being delegated to.
An EVENT-REPLY message is also sent from the Attendee delegating the
request to the organizer of the event request; indicating that the
original request is being delegated.
The EVENT-REQUEST message must assign the values of the RSVP and EXPECT
property parameters associated with the recipient delegating the request
to the ATTENDEE property of the delegate.
EVENT-REQUEST (delegation)
Calendar Properties
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"EVENT-REQUEST"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
COMMENT
Not Required
CREATED
Not Required
DAYLIGHT
Not Required
Silverberg/Mansour/Dawson/Hopson 38 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
DTSTART
Required
DTEND
Not Required
RDATE
Not Required, Either RDATE or
RRULE may be specified, but not
both.
RRULE
Not Required, Either RDATE or
RRULE may be specified, but not
both.
TZNAME
Not Required
TZOFFSET
Required
TZTRANS
Not Required
UID
Not Required
Event Component Properties
ATTACH
Not Required, VALUE=URL only.
Silverberg/Mansour/Dawson/Hopson 39 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
ATTENDEE
Required, Value is an RFC822
mailbox address. Required new
ATTENDEE property MUST be
included; corresponding to the
delegated individual. This
property should include the
DELEGATED-FROM property
parameter. The ATTENDEE property
must also have the same RSVP and
EXPECT property parameter values
as the recipient delegating the
request. The STATUS parameter for
this individual is either absent
or has Required value of "NEEDS
ACTION". The ATTENDEE property
associated with the recipient
delegating the request should
include the DELEGATED-TO property
parameter.
CATEGORIES
Not Required
CLASS
Not Required
CREATED
Not Required
COMMENT
Not Required, Text value.
Provides Required comment from
the organizer of the delegate
message to the delegated attendee
concerning the delegated event.
COMPLETED
Excluded
DESCRIPTION
Required, Value may be NULL text.
DUE
Excluded
DURATION
Excluded
DTEND
Not Required.
Silverberg/Mansour/Dawson/Hopson 40 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
DTSTAMP
Required
DTSTART
Required
EXDATE
Not Required, See issues list.
EXRULE
Not Required, See issues list.
LAST-MODIFIED
Not Required
LOCATION
Not Required
PRIORITY
Excluded
RELATED-TO
Not Required
REQUEST-STATUS
Excluded
RDATE
Not Required, See issues list.
RRULE
Not Required, See issues list.
RESOURCES
Not Required
RESPONSE-SEQUENCE
Excluded.
SEQUENCE
Required if not zero
STATUS
Not Required, Value only one of
TENTATIVE | CONFIRMED. This
property is used to convey the
consensus for the meeting. I
wonder if this should be set to
delegated
SUMMARY
Not Required, May be Null text.
Silverberg/Mansour/Dawson/Hopson 41 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
TRANSP
Excluded
URL
Not Required
UID
Required, Must be the UID of the
original EVENT-REQUEST.
To-do Component Properties
To-do component is excluded from
this message type.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
ATTACH
Not Required
CATEGORIES
Required, If an alarm is
specified
CREATED
Not Required
DESCRIPTION
Not Required
DTSTART
Required, If an alarm is
specified
DURATION
Required, If an alarm is
specified
LAST-MODIFIED
Not Required
RELATED-TO
Not Required
Silverberg/Mansour/Dawson/Hopson 42 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
REPEAT
Required, If an alarm is
specified
SUMMARY
Not Required
URL
Not Required
Freebusy Component Properties
Freebusy component is excluded
from this message type.
Non-standard Properties
Excluded-token
Not Required, but recipient may
choose to ignore those non-
standard properties, specified as
optional.
The following is the EVENT-REPLY to the organizer from the delegator
notifying the organizer that this attendee has delegated the item to
another.
EVENT-REPLY (From Delegator to Organizer)
Calendar Properties
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"EVENT-REPLY"
PROFILE-VERSION
Required, Value must be "1.0".
Silverberg/Mansour/Dawson/Hopson 43 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Timezone Component Properties
Timezone component is excluded
from this message type.
Event Component Properties
ATTACH
Excluded
ATTENDEE
Required, Value is an RFC822
mailbox address. Required
capability. Must be the address
of the recipient replying.
CATEGORIES
Excluded
CLASS
Excluded
COMMENT
Text value. Provides Required
comment from the recipient to the
originator about the reply. For
example, "I can't travel this far
for Required meeting."
CREATED
Excluded
COMPLETED
Excluded
DESCRIPTION
Excluded
DUE
Excluded
DURATION
Excluded
DTEND
Excluded
DTSTAMP
Required
Silverberg/Mansour/Dawson/Hopson 44 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
DTSTART
Excluded
EXDATE
Not Required, See issues list.
Specifies the dates that are
exceptions to the status update.
EXRULE
Not Required, See issues list.
Specifies the rule that defines
the exceptions to the status
update.
LAST-MODIFIED
Excluded
LOCATION
Excluded
PRIORITY
Excluded
RELATED-TO
Excluded
REQUEST-STATUS
Any of the values defined in the
table below.
RDATE
Excluded
RRULE
Excluded
RESOURCES
Excluded
RESPONSE-SEQUENCE
Required, if not zero.
SEQUENCE
Required, If not zero.
STATUS
Excluded Status for attendee must
be specified in STATUS parameter
of ATTENDEE property. Seems like
this should be delegated
Silverberg/Mansour/Dawson/Hopson 45 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
SUMMARY
Excluded
TRANSP
Excluded
URL
Excluded
UID
Required, Must be the UID of the
EVENT-REQUEST associate with the
reply.
To-do Component Properties
To-do component is excluded from
this message type.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
Alarm component is excluded from
this message type.
Freebusy Properties
Freebusy component is excluded
from this message type.
Non-Standard Properties
Excluded-token
Not Required, But recipient may
choose to ignore those non-
standard properties, specified as
Not Required.
3.2.9 BUSY-REQUEST
This design document only addresses the transfer of busy time
information. Applications desiring free time information must infer this
Silverberg/Mansour/Dawson/Hopson 46 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
from available busy time information. The Freebusy Calendar Component
MUST only be used in order to provide busy time information. The
Freebusy Calendar Component MAY only appear in the BUSY-REQUEST and
BUSY-REPLY message types or in a network resource containing busy time
data.
The busy time periods within the iCalendar Object MAY be grouped into
more than one Freebusy Calendar Component. This capability allows busy
time periods to be grouped according to some common periodicity, such as
a calendar week, month, or year. In this case, each FREEBUSY component
needs to include the ATTENDEE, DTSTART and DTEND properties to define
the free busy information in order that in might be unambiguous when
stored separately.
An iCalendar Object conforming to document MUST restrict the use of the
FREEBUSY property for representing busy time information.
The FREEBUSY property value MAY include a list of values, separated by
the COMMA character (ASCII decimal 44). Alternately, multiple busy time
periods MAY be specified with multiple instances of the FREEBUSY
property. Both forms MUST be supported by implementations conforming to
this document. Duplicate busy time periods SHOULD not be specified in an
iCalendar Object. However, two different busy time periods may overlap.
FREEBUSY properties SHOULD be sorted such that their values are in
ascending order, based on the start time, and then the end time, with
the earliest periods first. For example, today's busy time information
SHOULD appear after yesterday's busy time information. And the busy time
for this half hour SHOULD appear after the busy time for earlier today.
Since events MAY span a day boundary, free busy time period MAY also
span a day boundary. Individual "A" requests busy time from individuals
"B", "C" and "D". Individual "B" and "C" replies with busy time data to
individual "A". Individual "D" does not support busy time requests and
does not reply with any data. If the transport binding supports
exception messages, then a "unsupported capability" message is returned
by individual "D" to individual "A". The following table illustrates the
sequence of messages that would be exchanged between these individuals.
This message only permits requests for busy time information. The
message is sent from an organizer of a busy time request to one or more
intended recipients (i.e., ROLE=ATTENDEE).
BUSY-REQUEST
Calendar Properties
GEO
Not Required
Silverberg/Mansour/Dawson/Hopson 47 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"BUSY-REQUEST"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
COMMENT
Not Required
CREATED
Not Required
DAYLIGHT
Not Required
DTSTART
Required
DTEND
Not Required
RDATE
Not Required, Either RDATE or
RRULE may be specified, but not
both.
RRULE
Not Required, Either RDATE or
RRULE may be specified, but not
both.
TZNAME
Not Required
TZOFFSET
Required
TZTRANS
Not Required
UID
Not Required
Event Component Properties
Silverberg/Mansour/Dawson/Hopson 48 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Event component is excluded from
this message type.
To-do Component Properties
To-do component is excluded from
this message type.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
Alarm component is excluded from
this message type.
FreeBusy Component Properties
ATTENDEE
Required, Value is an RFC822
mailbox address. Not Required
capability. An instance must be
specified for the organizer and
the intended attendees of the
request.
COMMENT
Excluded
CREATED
Excluded
DURATION
Excluded
DTEND
Required, This is the end of the
busy time period being requested.
DTSTART
Required, This is the start of
the busy time period being
requested.
FREEBUSY
Excluded
Silverberg/Mansour/Dawson/Hopson 49 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
LAST-MODIFIED
Excluded
RELATED-TO
Excluded
REQUEST-STATUS
Excluded
RESPONSE-SEQUENCE
Excluded
SEQUENCE
Excluded
UID
Required, Must be referenced by
the recipients in their FREEBUSY-
REPLY message.
URL
Excluded
Non-standard Properties
Excluded-token
Not Required, but recipient may
choose to ignore those non-
standard properties, specified as
optional.
3.2.10 BUSY-REPLY
The message is used to reply to an existing busy time request. The
message is sent from a recipient of a busy time request back to the
request ORGANIZER. If an ORGANIZER is not specified on the busy time
request, then the message is sent to the OWNER.
Busy time intervals are represented by individual instances of the
FREEBUSY property. There is one occurrence of the property for each busy
time interval. Duplicate busy time periods should not be returned.
However, two different busy time periods may overlap.
The FREEBUSY property value MAY include a list of values, separated by
the COMA character (ASCII decimal 44).
FREEBUSY properties SHOULD be sorted such that their values are in
ascending order, from the most recent to past. For example, today's busy
time information SHOULD appear after yesterday's busy time information.
Silverberg/Mansour/Dawson/Hopson 50 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
And the busy time for this half hour SHOULD appear after the busy time
for earlier today.
Since events MAY span a day boundary, free busy time period MAY also
span a day boundary.
The busy time periods may be grouped into more than one FREEBUSY
component. This capability allows busy time periods to be grouped
according to some common periodicity, such as a calendar week, month, or
year. In this case, each FREEBUSY component needs to include the
ATTENDEE, DTSTART and DTEND properties.
The ATTENDEE property must be specified in the busy time reply. The
value is the fully qualified RFC 822 address of the recipient replying
to the busy time request.
BUSY-REPLY
Calendar Properties
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"BUSY-REPLY"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
COMMENT
Not Required
CREATED
Not Required
DAYLIGHT
Not Required
DTSTART
Required
DTEND
Not Required
Silverberg/Mansour/Dawson/Hopson 51 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
RDATE
Not Required, Either RDATE or
RRULE may be specified, but not
both.
RRULE
Not Required, Either RDATE or
RRULE may be specified, but not
both.
TZNAME
Not Required
TZOFFSET
Required
TZTRANS
Not Required
UID
Not Required
Event Component Properties
Event component is excluded from
this message type.
To-do Component Properties
To-do component is excluded from
this message type.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
Alarm component is excluded from
this message type.
Freebusy Component Properties
Silverberg/Mansour/Dawson/Hopson 52 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
ATTENDEE
Required, Value is an RFC822
mailbox address. Required
capability. Must be the address
of the recipient replying.
COMMENT
Not Required, Text value.
Provides Required comment from
the organizer of the reply to the
attendees concerning the busy
time reply notice.
CREATED
Not Required
DURATION
Excluded
DTEND
Not Required, Value is the ISO
8601 complete representation,
basic format of Required UTC
based date and time. Represents
the end of the busy time period
defined by the FREEBUSY
properties in the Freebusy
component.
DTSTART
Not Required, Value is the ISO
8601 complete representation,
basic format of Required UTC
based date and time. Represents
the start of the busy time period
defined by the FREEBUSY
properties in the Freebusy
component.
FREEBUSY
Required, Values in the property
must all be of the same property
parameter type. Multiple
instances of the property are
permitted. Multiple instances of
the property must be sorted in
ascending order. Values between
property instances may overlap.
LAST-MODIFIED
Not Required
Silverberg/Mansour/Dawson/Hopson 53 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
RELATED-TO
Not Required, Refers to Required
related Freebusy component.
REQUEST-STATUS
Required, One of the values from
the table below. Multiple
instances of the property may be
specified.
RESPONSE-SEQUENCE
Excluded
SEQUENCE
Excluded
UID
Required, Must be the UID of the
BUSY-REQUEST associated with the
reply.
URL
Not Required, Specifies the URL
for the data containing iCalendar
Object with busy time
information.
Non-standard Properties
Excluded-token
Not Required, Recipient may
choose to ignore those non-
standard properties, specified as
optional.
3.2.11 EVENT-RESEND
This message type is used by attendees to request the latest version of
an EVENT-REQUEST. By issuing an EVENT-RESEND with the appropriate UID
and optionally a RECURRENCE-ID, the organizer's CUA should respond with
the latest version of the Event. This message type is intended to be
machine processed.
EVENT-RESEND
Calendar Properties
Silverberg/Mansour/Dawson/Hopson 54 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
GEO Not Required
PRODID Required
VERSION Required, Value must be "2.0".
PROFILE Required,"EVENT-RESEND"
PROFILE-VERSION Required, Value must be "1.0".
Timezone Properties
Timezone component is excluded
from this message type.
Event Component Properties
ATTACH Excluded
ATTENDEE Required
CATEGORIES Excluded
CLASS Excluded
COMMENT Not Required, Text value.
Provides a comment from the
originator to the recipient
about the decline of the
counter proposal. For example,
"We are unable to change the
meeting time or place".
CREATED Excluded
COMPLETED Excluded
DESCRIPTION Excluded
DUE Excluded
DURATION Excluded
DTEND Excluded
DTSTAMP Required
DTSTART Excluded
EXDATE Excluded
EXRULE Excluded
Silverberg/Mansour/Dawson/Hopson 55 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
LAST-MODIFIED Excluded
LOCATION Excluded
PRIORITY Excluded
RELATED-TO Excluded
REQUEST-STATUS Excluded
RECURRENCE-ID Not Required, if the attendee
wishes to receive an updated
instance of a recurring event
then the RECURRENCE-ID can be
included and only the specific
instance will be returned.
RDATE Excluded
RRULE Excluded
RESOURCES Excluded
RESPONSE-SEQUENCE Excluded
SEQUENCE Required, if not zero. Is not
incremented by this action
STATUS Excluded
SUMMARY Excluded
TRANSP Excluded
URL Excluded
UID Required, The Event associated
with the UID represents the
Event that will be returned
To-do Component Properties
To-do component is excluded
from this message type.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
Silverberg/Mansour/Dawson/Hopson 56 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Alarm component is excluded
from this message type.
Freebusy Properties
Freebusy component is excluded
from this message type.
Non-standard Properties
X-token Excluded
3.3 Status Replies
The REQUEST-STATUS property may include the following values:
Short Longer Return Status Offending Data
Return Description
Status
Code
200
Success. None.
201
Success, but fallback taken Property name and value
on one or more property may be specified.
values.
202
Success, invalid property Property name may be
ignored. specified.
203
Success, invalid property Property parameter name
parameter ignored. and value may be
specified.
204
Success, unknown non- Non-standard property
standard property ignored. name may be specified.
205
Success, unknown non- Property and non-
standard property value standard value may be
ignored. specified.
Silverberg/Mansour/Dawson/Hopson 57 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
206
Success, invalid calendar Calendar component
component ignored. sentinel (e.g.,
"BEGIN:ALARM") may be
specified.
207
Success, request forwarded Original and forwarded
to calendar user. RFC822 addresses may be
specified.
208
Success, repeating event RRULE or RDATE property
ignored. Scheduled as a name and value may be
single event. specified.
209
Success, truncated end DTEND property value may
date/time to date boundary. be specified.
210
Success, repeating to-do RRULE or RDATE property
ignored. Scheduled as a name and value may be
single to-do. specified.
300
Invalid property name. Property name may be
specified.
301
Invalid property value. Property name and value
may be specified.
302
Invalid property parameter. Property parameter name
and value may be
specified.
303
Invalid property parameter Property parameter name
value. and value may be
specified.
304
Invalid calendar component Calendar component
sequence. sentinel may be
specified (e.g.,
BEGIN:TIMEZONE).
305
Invalid date or time. Date/time value(s) may
be specified.
Silverberg/Mansour/Dawson/Hopson 58 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
306
Invalid rule. Rule value may be
specified.
307
Invalid calendar user. Attendee property value
may be specified.
308
No authority. PROFILE and ATTENDEE
property values may be
specified.
309
Unsupported version. VERSION property name
and value may be
specified.
310
Request entity too large. None.
400
Event conflict. Date/time DTSTART and DTEND
is busy. property name and values
may be specified.
500
Request not supported. Profile property value
may be specified.
501
Service unavailable. ATTENDEE property value
may be specified.
502
Invalid calendar service. ATTENDEE property value
may be specified.
503
No scheduling support for ATTENDEE property value
user. may be specified.
3.4 Implementation Considerations
3.4.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
Silverberg/Mansour/Dawson/Hopson 59 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
events in a single object. However, while this simplifies creation of a
recurring event, meeting instances may 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 can be both
referenced and versioned. Hence, implementations that choose to maintain
per-instance properties (such as attendee status) 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 affect on the
meeting itself such as start time, location, due date (for to-do
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, when that instance must be renegotiated. Negotiation is
necessary when the start time, end time, due date or location are
modified. If the Organizer wishes to identify a specific recurrence
instance it is done 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
and the new DTSTART and DTEND values reflect the change. If the
Organizer wishes to add a new instance to the recurring event then an
Event-Request is issued with an RDATE equal to the new instance date. It
is recommended that the Organizer include the RECURRENCE-ID. Since the
creation of a new event instance requires negotiation, the sequence
number is also incremented.
3.4.2 When To Resend An Event
The following table is used to determine when the change to a component
or property should cause the event to be resent to all attendees. The
Resend Event key is:
. Resend _ The event must be resent
. Resend Not Required _ An application may resend the event if it
wants, but it is not required
Silverberg/Mansour/Dawson/Hopson 60 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
. Do Not Resend _ An application must not resend the event
. Excluded _ this property should not appear in the event.
EVENT-REQUEST (when to resend)
Calendar Properties
GEO Resend Not Required
PRODID Do Not Resend
VERSION Do Not Resend
PROFILE Do Not Resend
PROFILE-VERSION Do Not Resend
Timezone Component Properties
COMMENT Do Not Resend
CREATED Resend Not Required
DAYLIGHT Resend
DTSTART Resend
DTEND Resend
RDATE Resend
RRULE Resend
TZNAME Resend Not Required
TZOFFSET Resend
TZTRANS Resend
UID Resend Not Required
Event Component Properties
ATTACH Resend
ATTENDEE Resend
CATEGORIES Resend Not Required
CLASS Resend Not Required
Silverberg/Mansour/Dawson/Hopson 61 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
CREATED Do Not Resend
COMMENT Excluded
COMPLETED Do Not Resend
DESCRIPTION Resend
DUE Excluded
DURATION Excluded
DTEND Resend
DTSTART Resend
EXDATE Resend
EXRULE Resend
LAST-MODIFIED Do Not Resend
LOCATION Resend
PRIORITY Excluded
RELATED-TO Resend
REQUEST-STATUS Excluded
RDATE Resend
RRULE Resend
RESOURCES Resend
RESPONSE-SEQUENCE Excluded
SEQUENCE Resend if not zero
STATUS Resend
SUMMARY Resend
TRANSP Excluded
URL Resend
UID Does not change once set
To-do Component Properties
Silverberg/Mansour/Dawson/Hopson 62 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
To-do component is excluded from
this message type.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
ATTACH Resend
CATEGORIES Resend
CREATED Do Not Resend
DESCRIPTION Resend
DTSTART Resend
DURATION Resend
LAST-MODIFIED Do Not Resend
RELATED-TO Resend
REPEAT Resend
SUMMARY Resend
URL Resend
Freebusy Component Properties
Freebusy component is excluded
from this message type.
Non-standard Properties
Excluded-token
Resend Not Required, but
recipient may choose to ignore
those non-standard properties,
specified as optional.
Silverberg/Mansour/Dawson/Hopson 63 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
3.4.3 Timezones
If a recurring event has any instance where DTStart and DTEnd fall on
different sides of a timezone shift, the Timezone components are
required.
The threat of duplicate timezone definitions exists. Should an iCalendar
Object contain multiple conflicting timezone components, the one with
the latest DTSTART property supersedes the others.
3.4.4 Alarms
Alarms are a contentious component. It is recommended that application
software ask the user whether or not they want alarms included when they
read the event.
3.4.5 SUMMARY Property
The minimum support for the SUMMARY property in a recipient MUST be for
a 255 byte value. Implementations MAY truncate longer length values.
3.4.6 X-Tokens
To make iCalendar Objects extensible, new property types can 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 event replies.
Silverberg/Mansour/Dawson/Hopson 64 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
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 can be 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 Attendee
Publish an event "A" sends or posts an
EVENT-PUBLISH message
"B" reads the event
publication
Publish an updated "A" sends or posts an
event EVENT-PUBLISH message
"B" reads the updated
event publication
Cancel a published "A" sends or posts an
event EVENT-CANCEL message
"B" reads the
canceled event
publication
Silverberg/Mansour/Dawson/Hopson 65 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
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 an iTIP event component.
BEGIN:VCALENDAR
PROFILE:EVENT-PUBLISH
PROFILE-VERSION:1.0
PRODID:-//ACME/DesktopCalendar//EN
VERSION:2.0
BEGIN:VEVENT
DTSTART:19970701T200000Z
DTSTAMP:19970611T190000Z
SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
UID:0981234-1234234-23
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
PROFILE:EVENT-PUBLISH
PROFILE-VERSION:1.0
VERSION:2.0
PRODID:-//ACME/DesktopCalendar//EN
BEGIN:VEVENT
DTSTAMP:19970612T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SEQUENCE:2
UID:0981234-1234234-23
SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
END:VEVENT
END:VCALENDAR
The UID is used by the client to identify the event. The SEQUENCE
property indicates that this is the second change to the event. Events
with sequence numbers 0 and 1 are 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 should not be updated.
Silverberg/Mansour/Dawson/Hopson 66 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
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 numbers 0, 1, and 2.
BEGIN:VCALENDAR
PROFILE:EVENT-CANCEL
PROFILE-VERSION:1.0
VERSION:2.0
PRODID:-//ACME/DesktopCalendar//EN
BEGIN:VEVENT
COMMENT:DUKES forfeit the game
SEQUENCE:2
UID:0981234-1234234-23
DTSTAMP:19970613T190000Z
STATUS:CANCELLED
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
BEGIN:VTIMEZONE
DAYLIGHT:TRUE
DTSTART:19970406T000000
RRULE;BYDAY=1SU;BYMONTH=4;FREQ=YEARLY
TZNAME:CDT
TZOFFSET:-0500
TTRANS:020000
END:VTIMEZONE
BEGIN:VTIMEZONE
DAYLIGHT:FALSE
DTSTART:19970101T000000
RRULE;BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY
TZNAME:CST
TZOFFSET:-0600
TTRANS:020000
END:VTIMEZONE
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-PUBLISH
PROFILE-VERSION:1.0
CALSCALE:GREGORIAN
SOURCE:http://www.midwaystadium.com/stadium-cal/1997-events.or4
NAME:1997 GAME SCHEDULE
VERSION:2.0
BEGIN:VEVENT
ATTACH:http://www.stadium.com/bigame.gif
CATEGORIES:SPORTS EVENT;ENTERTAINMENT
CLASS:PRIVATE
Silverberg/Mansour/Dawson/Hopson 67 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
CREATED:19970415T194319Z
DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:MIDWAY=
STADIUM=0A=0D=
Big time game. Must see.=
Expected duration:2 hours
DTEND:19970701T180000
DTSTART:19970702T160000
DTSTAMP:19970614T190000Z
STATUS:CONFIRMED
LAST-MODIFIED:19970416T162421Z
LOCATION;VALUE=URL:http://www.midwaystadium.com/
PRIORITY:2
RESOURCES:SCOREBOARD
SEQUENCE:3
SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
UID:0981234-1234234-23
RELATED-TO:0981234-1234234-14
BEGIN:VALARM
DTSTART:19970701T190000Z
REPEAT:2
DURATION:PT2H
CATEGORIES:DISPLAY,AUDIO
DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:It's almost
game time
END:VALARM
BEGIN:VALARM
DTSTART:19970701T153000
CATEGORIES:DISPLAY,AUDIO
DESCRIPTION:You should leave now. Game starts in 30 min!
END:VALARM
END:VEVENT
END:VCALENDAR
The CLASS property is specified, though it is not really needed here.
Since this is a published event, a program that displays it need not
apply any content filtering based on the CLASS attribute. If this event
is copied into a user's calendar, the CLASS would be included as part of
the copy. The handling of the CLASS tag at that point is implementation
specific.
The RELATED-TO field contains the UID of a related calendar event. The
handling of this property is application dependent.
VTIMEZONE components are discussed in detail in [ICAL].
The sequence number 3 indicates that this event supersedes versions 0,
1, and 2.
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 with
respect to the event. Individual "A" requests a meeting between
Silverberg/Mansour/Dawson/Hopson 68 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
individuals "A", "B", "C" and "D". Individual "B" confirms attendance to
the meeting. Individual "C" declines attendance. Individual "D"
tentatively confirms their attendance. This is sometimes referred to as
"penciling-in" the event on a calendar. The following table illustrates
the sequence of messages that would be exchanged between these
individuals. The table below illustrates the message flow.
Action Organizer Attendee
Initiate a
meeting REQUEST message to
"A" sends EVENT-
request "B", "C", and "D"
Accept the "B" sends EVENT-REPLY
meeting message to "A" with
request it's ATTENDEE/STATUS
property parameter set
to "ACCEPTED"
Decline the "C" sends EVENT-REPLY
meeting message to "A" with
request it's ATTENDEE/STATUS
property parameter set
to "DECLINED"
Tentatively "D" sends EVENT-REPLY
accept the message to "A" with
meeting it's ATTENEE/STATUS
request property parameter set
to "TENTATIVE"
Confirm "A" sends EVENT-
meeting status REQUEST message to
with attendees "B" and "C" with
current information
for event. SEQUENCE
property is "1".
4.2.1 A Group Event Request
A sample meeting request that "A" sends to "B", "C", and "D".
Silverberg/Mansour/Dawson/Hopson 69 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-REQUEST
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:D@acme.com
ATTENDEE;RSVP=NO;EXPECT=REQUIRE;TYPE=ROOM:The Big Conference Room
DTSTAMP:19970611T190000Z
DTSTART:19970701T100000-0700
DTEND:19970701T103000-0700
SUMMARY:Phone Conference
UID:www.acme.com-873970198738777
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
Note that the conference room does not have a valid e-mail address.
4.2.2 Reply To A Group Event Request
Attendee "B" accepts the meeting.
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-REPLY
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;STATUS=ACCEPTED:B@acme.com
UID:www.acme.com-873970198738777
SEQUENCE:0
RESPONSE-SEQUENCE:0
REQUEST-STATUS:200;Success
DTSTAMP:19970612T190000Z
END:VEVENT
END:VCALENDAR
"B" could have declined the meeting or indicated tentative acceptance by
setting the ATTENDEE;STATUS parameter to DECLINED or TENTATIVE,
respectively.
4.2.3 Update An Event
The event is moved to a different time. The combination of the UID
(which remains the same) and the SEQUENCE (bumped to 1) properties
indicate the update.
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
Silverberg/Mansour/Dawson/Hopson 70 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
PROFILE:EVENT-REQUEST
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:D@acme.com
ATTENDEE;RSVP=NO;EXPECT=REQUIRE;TYPE=ROOM:The Big Conference Room
DTSTART:19970701T110000-0700
DTEND:19970701T113000-0700
SUMMARY:Phone Conference
UID:www.acme.com-873970198738777
SEQUENCE:1
DTSTAMP:19970613T190000Z
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
4.2.4 Countering an Event Proposal
Attendee A sends EVENT-REQUEST to B and C. B makes a counter proposal to
A to change the time and location.
Attendee A sends EVENT-REQUEST:
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-REQUEST
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com
DTSTART:19970701T190000Z
DTEND:19970701T200000Z
SUMMARY:Discuss the Merits of the election results
LOCATION:The Big Conference Room
UID:www.acme.com-873970198738777
SEQUENCE:0
DTSTAMP:19970611T190000Z
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
Attendee B sends EVENT-COUNTER to A requesting changes to time and
place:
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-COUNTER
PROFILE-VERSION:1.0
VERSION:2.0
Silverberg/Mansour/Dawson/Hopson 71 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
BEGIN:VEVENT
ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com
DTSTART:19970701T160000Z
DTEND:19970701T190000Z
DTSTAMP:19970612T190000Z
SUMMARY:Discuss the Merits of the election results
LOCATION:The Small Conference Room
COMMENT:This time works much better and I think the big conference
room is too big
UID:www.acme.com-873970198738777
SEQUENCE:0
DTSTAMP:19970611T190000Z
END:VEVENT
END:VCALENDAR
Attendee A accepts the changes from B
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-REQUEST
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com
DTSTAMP:19970613T190000Z
DTSTART:19970701T160000Z
DTEND:19970701T190000Z
SUMMARY:Discuss the Merits of the election results - changed to suite
B's schedule
LOCATION:The Small Conference Room
UID:www.acme.com-873970198738777
SEQUENCE:1
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
A rejects B's counter proposal
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-COUNTERDECLINE
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com
COMMENT:Sorry, I cannot change this meeting time
UID:www.acme.com-873970198738777
SEQUENCE:1
DTSTAMP:19970614T190000Z
Silverberg/Mansour/Dawson/Hopson 72 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
END:VEVENT
4.2.5 Delegate An Event
When delegating an event request to another calendar user, the delegator
must both update the organizer with an Event-Reply and send an EVENT-
REQUEST to the delegatee. There is currently no protocol limitation to
delegation depth. That is, it is possible for the original delegate to
delegate the meeting to someone else, and so on. When an Event-Request
is delegated from one CUA to another there are a number of
responsibilities required of the delegator. They must:
. Send an Event-Reply to the organizer with their attendee/status
property parameter set to "Delegated"
. Include the delegate as an additional attendee with the
"Delegated-From" property parameter set to the delegator
. Set the response sequence equal to 0
. Include the original UID of the Event-Request
The delegator must also send a copy of the original Event-Request to the
delegate. The delegator modifies the request to include:
. The ATTENDEE/STATUS property parameter for the delegator (sender
in this case) is set to "DELEGATED"
. ATTENDEE/DELEGATED-TO parameter is set to the address of the
delegatee
. An ATTENDEE property is added for delegatee
As a rule, it is not required that the delegatee include the delegator
in their Event-Reply. However, it is strongly advised since this will
inform the delegator whether their proxy plans to attend the meeting. If
the delegatee declines the meeting, the delegator may elect to try and
delegate the Event-Request to another CUA. The process is the same.
Action Organizer Attendee
Initiate "A" sends EVENT-
a REQUEST message
meeting to "B" and "C"
request
Silverberg/Mansour/Dawson/Hopson 73 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Delegate "C" sends EVENT-REPLY message
the to "A" with it's
meeting ATTENDEE/STATUS property
request. parameter set to "DELEGATED"
"C" and an ATTENDEE property has
delegate been added to the reply for "E"
s the with a DELEGATED-FROM property
meeting parameter set to address of
to "E" "C". DELEGATED-TO property
parameter for "B" set to
address of "E".
"C" sends EVENT-REQUEST message
to "E" with the original
meeting request information.
The ATTENDEE/STATUS property
parameter for "C" has been set
to "DELEGATED" and the
ATTENDEE/DELEGATED-TO parameter
has been set to the address of
"E". An ATTENDEE property has
been added for "E" and the
ATTENDEE/DELEGATED-FROM
parameter has been set to the
address of "C".
Confirm "E" sends EVENT-REPLY message
meeting to "A" and optionally "C", with
attendan it's ATTENDEE/STATUS property
ce parameter set to "ACCEPTED"
Optional "A" sends EVENT-
REQUEST message
Redistri to "B" and "E"
bute with current
meeting information for
details event. SEQUENCE
and property is "1"
status
to
attendee
s
Attendee "C" responds to meeting organizer "A"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
Silverberg/Mansour/Dawson/Hopson 74 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
PROFILE:EVENT-REPLY
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED-
TO=E@acme.com:C@acme.com
UID:www.acme.com-873970198738777
SEQUENCE:0
RESPONSE-SEQUENCE:0
REQUEST-STATUS:200;Success
DTSTAMP:19970611T190000Z
END:VEVENT
END:VCALENDAR
Attendee "C" delegates presence at the meeting to "E".
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-REQUEST
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=Organizer;STATUS=ACCEPTED:A@acme.com
ATTENDEE;ROLE=DELEGATE;RSVP=YES;EXPECT=REQUEST;DELEGATED-
FROM=C@acme.com:E@acme.com
ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED-
TO=E@acme.com:C@acme.com
DTSTART:19970701T110000-0700
DTEND:19970701T113000-0700
SUMMARY:Phone Conference
UID:www.acme.com-873970198738777
SEQUENCE:0
STATUS:CONFIRMED
DTSTAMP:19970611T190000Z
END:VEVENT
END:VCALENDAR
4.2.6 Delegate Accepts the Meeting
To accept a delegated meeting, the delegate sends the following message
to "A" and "C"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-REPLY
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED;DELEGATED-
FROM=C@acme.com:E@acme.com
UID:www.acme.com-873970198738777
SEQUENCE:1
RESPONSE-SEQUENCE:0
Silverberg/Mansour/Dawson/Hopson 75 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
REQUEST-STATUS:200;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 status to declined. The organizer should resend the EVENT-
REQUEST to "C" with the status 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 or delegate the request.
Response from "E" to "A" and "C"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-REPLY
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=ATTENDEE;STATUS=DECLINED;DELEGATED-
FROM=C@acme.com:E@acme.com
UID:www.acme.com-873970198738777
SEQUENCE:1
RESPONSE-SEQUENCE:0
REQUEST-STATUS:200;Success
DTSTAMP:19970614T190000Z
END:VEVENT
END:VCALENDAR
"A" resends the EVENT-REQUEST to "C". "A" may also wish to express the
fact that the item was delegated in the COMMENT field
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-REPLY
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=ATTENDEE;STATUS=DECLINED;DELEGATED-
FROM=C@acme.com:E@acme.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com
UID:www.acme.com-873970198738777
SEQUENCE:2
REQUEST-STATUS:200;Success
DTSTAMP:19970614T200000Z
COMMENT:DELEGATE (ATTENDEE E@acme.com) DECLINED YOUR INVITATION
END:VEVENT
END:VCALENDAR
Silverberg/Mansour/Dawson/Hopson 76 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
4.2.8 Cancel A Group Event
Individual "A" requests a meeting between individuals "A", "B" and "C".
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 number is less
than the SEQUENCE number of the EVENT-CANCEL message) or to-do must be
ignored.
Action Organizer Attendee
Initiate a "A" sends EVENT-
meeting request REQUEST message to
"B" and "C"
Decline the "B" sends EVENT-
meeting request REPLY message to "A"
with it's
ATTENDEE/STATUS
property parameter
set to "DECLINED".
"C" may or may not
reply to the EVENT-
REQUEST message.
Cancel the "A" sends EVENT-
meeting CANCEL message to
"B" and "C" to
cancel the meeting.
SEQUENCE parameter
is "1".
The example shows how "A" cancels the event.
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-CANCEL
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
COMMENT:Mr. B cannot attend. I'll reschedule the meeting later.
UID:www.acme.com-873970198738777
Silverberg/Mansour/Dawson/Hopson 77 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
SEQUENCE:0
DTSTAMP:19970613T190000Z
STATUS:CANCELLED
END:VEVENT
END:VCALENDAR
The organizer of a meeting can "uninvite" or remove attendees by sending
an EVENT-CANCEL to only those attendees.
4.3 Busy Time Examples
Individual "A" requests busy time from individuals "B", "C" and "D".
Individual "B" and "C" replies with busy time data to individual "A".
Individual "D" does not support busy time requests and does not reply
with any data.
The following table illustrates the sequence of messages that would be
exchanged between these individuals.
Action Organizer Attendee
Initiate a busy time "A" sends BUSY-
request REQUEST message
to "B", "C" and
"D"
Reply to the busy time "B" and "C" sends
request with busy time BUSY-REPLY
data message to "A"
with their busy
time data.
4.3.1 Request Busy Time
"A" sends a BUSY-REQUEST to "B", "C", and "D" for busy time
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:BUSY-REQUEST
VERSION:2.0
PROFILE-VERSION:1.0
BEGIN:FREEBUSY
ATTENDEE;ROLE=OWNER:A@acme.com
ATTENDEE:B@acme.com
ATTENDEE:C@acme.com
ATTENDEE:D@acme.com
Silverberg/Mansour/Dawson/Hopson 78 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
DTSTAMP:19970613T190000Z
DTSTART:19970701T080000-0700
DTEND:19970701T200000-0700
UID:www.acme.com-873970198738777
END:VEVENT
END:VCALENDAR
4.3.2 Reply To A Busy Time Request
"B" sends a BUSY-REPLY to "A"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:BUSY-REPLY
VERSION:2.0
PROFILE-VERSION:1.0
BEGIN:FREEBUSY
ATTENDEE:B@acme.com
DTSTART:19970701T080000-0700
DTEND:19970701T200000-0700
UID:www.acme.com-873970198738777
FREEBUSY:19970701T090000-0700/PT1H,19970701T140000-0700/PT30H
DTSTAMP:19970613T190030Z
END:VEVENT
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 Timezones
This event describes a weekly phone conference. The attendees are each
in a different timezone.
BEGIN:VCALENDAR
BEGIN:VTIMEZONE
DAYLIGHT:TRUE
DTSTART:19970406T000000
RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY
TZNAME:PDT
TZOFFSET:-0700
TTRANS:020000
END:VTIMEZONE
BEGIN:VTIMEZONE
DAYLIGHT:FALSE
DTSTART:19970126T000000
RRULE;BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY
TZNAME:PST
TZOFFSET:-0800
TTRANS:020000
END:VTIMEZONE
Silverberg/Mansour/Dawson/Hopson 79 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:EVENT-REQUEST
VERSION:2.0
BEGIN:VEVENT
ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:sman@mcom.com
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:gb@mcom.fr
ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:kimiko@mcom.jp
DTSTAMP:19970613T190030Z
DTSTART:19970701T140000
DTEND:19970701T150000
RRULE:INTERVAL=20;WKST=SU;BYDAY=TU;FREQ=WEEKLY
RDATE:19970910T140000
EXDATE:19970909T140000
EXDATE:19971028T150000
SUMMARY:Weekly Phone Conference
UID:www.acme.com-873970198738777
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
Timezone components should appear in an iCalendar Object containing
recurring events. This is especially important if a recurring event has
attendees in different timezones. There can be multiple VTIMEZONE
components in an iCalendar Object, however, they must be used to define
the same timezone. That is, there cannot be VTIMEZONE components
describing both PST/PDT and EST/EDT at the component level in the same
iCalendar Object.
The first two components of this iCalendar Object are the timezone
components. The DTStart date coincides with the first instance of the
RRULE property.
The recurring meeting is defined in a particular timezone, presumably
that of the creator. The client for each attendee has the responsibility
of determining the recurrence time in the attendee's timezone.
The repeating event starts on Tuesday, July 1, 1997 at 2:00pm. Since no
timezone is specified in the DTSTART property, the timezone component of
PDT applies to the start and end times. Attendee gb@mcom.fr is in France
where the local time on this date is 7 hours later than PDT or 21:00.
Attendee kimiko@mcom.jp is in Japan where local time is 9 hours ahead of
than UTC or Wednesday, July 2 at 07:00. The event repeats weekly on
Tuesdays (in PST/PDT). The RRULE results in 20 instances. The last
instance falls on Tuesday, November 11, 1997 2:00pm PST. The RDATE adds
another instance: WED, 10-SEP-1997 21:00 GMT.
There are two exceptions to this recurring appointment. The first one
is:
Silverberg/Mansour/Dawson/Hopson 80 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
TUE, 09-SEP-1997 21:00 GMT
TUE, 09-SEP-1997 14:00 PDT
WED, 10-SEP-1997 07:00 JDT
and the second is:
TUE, 28-OCT-1997 22:00 GMT
TUE, 28-OCT-1997 14:00 PST
WED, 29-OCT-1997 07: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. Note
the use of RECURRENCE-ID and SEQUENCE-NUMBER in the second request.
Original Request:
BEGIN:VCALENDAR
PROFILE:EVENT-REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:19970526T083000
UID:guid-1.host1.com
SEQUENCE:0
RRULE:BYMONTHDAY=1;FREQ=MONTHLY;UNTIL=19980901T210000Z
ATTENDEE;EXPECT=REQUEST:Sman@netscape.com
ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net
ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com
ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com
DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970601T210000Z
DTEND:19970601T220000Z
LOCATION:Conference Call
DTSTAMP:19970526T083000
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
The event request below is to change a time and create an exception.
This creates an exception on July 3rd.
BEGIN:VCALENDAR
PROFILE:EVENT-REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:19970526T083000
UID:guid-1.host1.com
Silverberg/Mansour/Dawson/Hopson 81 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
RECURRENCE-ID:19970701T210000Z
SEQUENCE:1
RRULE:BYMONTHDAY=1;FREQ=MONTHLY;UNTIL=19980901T210000Z
ATTENDEE;EXPECT=REQUEST:Sman@netscape.com
ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net
ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com
ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com
DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970703T210000Z
DTEND:19970703T220000Z
LOCATION:Conference Call
DTSTAMP:19970626T093000
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
4.4.3 Cancel A Recurring Instance
In this example the Organizer of a recurring event wishes to delete an
instance. This is referred to as an "exception" to the recurring event.
BEGIN:VCALENDAR
PROFILE:EVENT-CANCEL
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VEVENT
UID:guid-1.host1.com
RECURRENCE-ID:19970801T210000Z
SEQUENCE:2
DTSTAMP:19970721T093000
STATUS:CANCELLED
END:VEVENT
END:VCALENDAR
4.4.4 Cancel An Exception
In the following example, the organizer has created an exception and now
wishes to cancel it. In this case an EVENT-CANCEL is sent with the
specific RECURRENCE-ID, UID, and SEQUENCE of the exception. This same
sequence can be used to decline a previously accepted modification to a
recurring event.
BEGIN:VCALENDAR
PROFILE:EVENT-CANCEL
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VEVENT
UID:guid-1.host1.com
RECURRENCE-ID:19970801T210000Z
SEQUENCE:2
DTSTAMP:19970721T103000
STATUS:CANCELLED
Silverberg/Mansour/Dawson/Hopson 82 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
END:VEVENT
END:VCALENDAR
4.4.5 Cancel Recurring Event
In this example the organizer wishes to cancel the entire recurring
event and any child exceptions.
BEGIN:VCALENDAR
PROFILE:EVENT-CANCEL
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VEVENT
UID:guid-1.host1.com
DTSTAMP:19970721T103000
SEQUENCE:2
STATUS:CANCELLED
END:VEVENT
END:VCALENDAR
4.4.6 Change All Future Instances
This example changes the meeting location from a conference call to
Seattle starting Sept 1 and extends to all future instances.
BEGIN:VCALENDAR
PROFILE:EVENT-REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:19970526T083000
UID:guid-1.host1.com
RECURRENCE-ID;THISANDFUTURE:19970901T210000Z
SEQUENCE:3
RRULE:BYMONTHDAY=1;FREQ=MONTHLY;UNTIL=19980901T210000Z
ATTENDEE;EXPECT=REQUEST:Sman@netscape.com
ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net
ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com
ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com
DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970901T210000Z
DTEND:19970901T220000Z
LOCATION:Building 32, Microsoft, Seattle, WA
DTSTAMP:19970526T083000
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
4.4.7 Add A New Instance To A Recurring Event
This example adds a one-time additional Event instance to the recurring
Event. Organizer adds a second July meeting on the 15th.
Silverberg/Mansour/Dawson/Hopson 83 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
BEGIN:VCALENDAR
PROFILE:EVENT-REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:19970526T083000
UID:guid-1.host1.com
RECURRENCE-ID:19970715T210000Z
SEQUENCE:4
RRULE:BYMONTHDAY=1;FREQ=MONTHLY;UNTIL=19980901T210000Z
RDATE:19970715T210000Z/19970715T220000Z
ATTENDEE;EXPECT=REQUEST:Sman@netscape.com
ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net
ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com
ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com
DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970715T210000Z
DTEND:19970715T220000Z
LOCATION:Conference Call
DTSTAMP:19970629T093000
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
4.4.8 Counter An Instance Of A Recurring Event
In this example one of the attendees counters the DTSTART of the
proposed second July meeting.
BEGIN:VCALENDAR
PROFILE:EVENT-COUNTER
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:19970526T083000
UID:guid-1.host1.com
RECURRENCE-ID:19970715T210000Z
SEQUENCE:4
RRULE:BYMONTHDAY=1;FREQ=MONTHLY;UNTIL=19980901T210000Z
ATTENDEE;EXPECT=REQUEST:Sman@netscape.com
ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net
ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com
ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com
DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970715T220000Z
DTEND:19970715T230000Z
LOCATION:Conference Call
COMMENT:Can we bump this by an hour? I have a conflict
DTSTAMP:19970629T094000
Silverberg/Mansour/Dawson/Hopson 84 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
END:VEVENT
END:VCALENDAR
4.4.9 Error Reply To An EVENT-REQUEST
The following example illustrates a scenario where a meeting is proposed
that contains a property that is not supported (in this case, RRULE).
Original Request:
BEGIN:VCALENDAR
PROFILE:EVENT-REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:19970526T083000
UID:guid-1.host1.com
SEQUENCE:0
RRULE:BYMONTHDAY=1;FREQ=MONTHLY
ATTENDEE;EXPECT=REQUEST:Sman@netscape.com
ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net
ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com
ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com
DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970601T210000Z
DTEND:19970601T220000Z
DTSTAMP:19970602T094000
LOCATION:Conference Call
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
Response to indicate that RRULE is not supported:
BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN
PROFILE:EVENT-REPLY
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
REQUEST-STATUS:208;Repeating event ignored. Scheduled as a single
event;RRULE
UID:guid-1.host1.com
SEQUENCE:0
RESPONSE-SEQUENCE:0
DTSTAMP:19970603T094000
END:VEVENT
END:VCALENDAR
Silverberg/Mansour/Dawson/Hopson 85 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
5 Application Protocol Fallbacks
Applications that support iTIP are not required to support the entire
protocol. The following describes how profiles and properties should
"Fallback" in applications that do not support the complete protocol. If
a profile or property is not addressed in this section, it may be safely
ignored.
5.1 Profiles
Profile Fallback
EVENT-PUBLISH Required.
EVENT-CANCEL Required.
EVENT-REQUEST EVENT-PUBLISH
EVENT-REPLY Required.
EVENT-DELEGATE Reply with Not Supported.
FREEBUSY-REQUEST Reply with Not Supported.
FREEBUSY-REPLY Reply with Not Supported.
EVENT-COUNTER Reply with Not Supported
EVENT- Required if EVENT-COUNTER is implemented;
COUNTERDECLINE otherwise reply with Not Supported.
5.2 Calendar Components
Component Fallback
Silverberg/Mansour/Dawson/Hopson 86 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
VFREEBUSY Reply with Not Supported.
VALARM Reply with Not Supported.
VTIMEZONE Required if RRULE or RDATE is implemented;
otherwise ignore and use local time.
5.3 Calendar Properties
Property Fallback
CALSCALE Ignore; assume GREGORIAN.
GEO Ignore.
PRODID Ignore.
PROFILE Required as described in the Profiles
section above.
PROFILE-VERSION Ignore.
SOURCE Ignore
NAME Ignore.
VERSION Ignore.
5.4 Component Properties
Silverberg/Mansour/Dawson/Hopson 87 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Property Fallback
ATTACH Ignore.
ATTENDEE Required if EVENT-REQUEST is not
implemented; otherwise reply with Not
Supported.
CATEGORIES Required if in VALARM and VALARM is
implemented, otherwise ignore.
CLASS Ignore.
COMMENT Ignore.
COMPLETED Ignore.
CREATED Ignore.
DAYLIGHT Required if VTIMEZONE is implemented;
otherwise Ignore.
DESCRIPTION Required.
DELEGATED-FROM Required if EVENT-DELEGATE is implemented;
otherwise Ignore.
DELEGATED-TO Required if EVENT-DELEGATE is implemented;
otherwise Ignore.
DUE Ignore.
DURATION Reply with Not Supported.
DTSTART Required.
Silverberg/Mansour/Dawson/Hopson 88 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
DTEND Required.
EXDATE Ignore.
EXRULE Ignore.
FREEBUSY Reply with Not Supported.
LAST-MODIFIED Ignore.
LOCATION Required.
PRIORITY Ignore.
RELATED-TO Ignore.
RDATE Ignore. If implemented, VTIMEZONE must
also be implemented.
RRULE Ignore. The first instance occurs on the
DTStart property.
RECURRENCE-ID Required if RRULE is implemented;
otherwise Ignore.
REQUEST-STATUS Required.
RESOURCES Ignore.
SEQUENCE Required.
STATUS Ignore.
SUMMARY Ignore.
Silverberg/Mansour/Dawson/Hopson 89 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
TRANSP Required if FREEBUSY is implemented;
otherwise Ignore.
TZNAME Required if VTIMEZONE is implemented;
otherwise Ignore.
TZOFFSET Required if VTIMEZONE is implemented;
otherwise Ignore.
TZTRANS Required if VTIMEZONE is implemented;
otherwise Ignore.
URL Ignore.
UID Required.
X- Ignore.
5.5 Latency Issues
With a store-and-forward transport, it is possible for events to arrive
out of sequence. That is, you may receive an EVENT-CANCEL notification
prior to receiving the original event. This section discusses a few of
these scenarios.
5.5.1 Cancelation of an Unknown Event.
When an EVENT-CANCEL request is received before the original EVENT-
REQUEST the calendar will be unable to correlate the UID of the
cancellation with an existing event. It is suggested that messages that
cannot be correlated that also contain non-zero sequence numbers be held
and not discarded. Implementations can age them out if no other messages
arrive with the same UID and a lower sequence number.
5.5.2 Unexpected Reply from an Unknown Delegate
When an attendee delegates an item to another calendar user they must
send an EVENT-REPLY to the organizer using the attendee properties to
indicate the fact that the request was delegated and to whom the item
was delegated. Hence it is possible for an organizer to receive an
EVENT-REPLY from a calendar user not listed as one of the original
attendees. The resolution is left to the implementation but it is
expected that the calendaring software will either accept the reply or
Silverberg/Mansour/Dawson/Hopson 90 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
hold it until the Event-Response is received from the delegator. If the
version of the EVENT-REPLY is out of date the Organizer should treat the
message as a STATUS-REQUEST and update the delegate with the correct
version.
5.6 Sequence Number
Under some conditions, a CUA may receive requests and replies with the
same SEQUENCE number. DTSTAMP is added to act as a tiebreaker when two
items with the same SEQUENCE number are evaluated. Furthermore, the
SEQUENCE number is only incremented when one or more of the following
properties changes:
. DTSTART
. DTEND
. LOCATION
. DUE (for To-Do components)
Silverberg/Mansour/Dawson/Hopson 91 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
6 Security Considerations
ITIP outlines an abstract transport protocol which will be bound to a
real-time transport, a store-and-forward transport, and perhaps other
transports. The transport protocol provides facilities for simple
authentication using a clear text password, as well as any SASL
mechanism [SASL]. SASL allows for integrity and privacy services to be
negotiated.
Use of clear text password is strongly discouraged where the underlying
transport service cannot guarantee confidentiality and may result in
disclosure of the password to unauthorized parties.
Silverberg/Mansour/Dawson/Hopson 92 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
7 Acknowledgments
A hearty thanks to the following individuals who have participated in
the drafting, review and discussion of this memo:
Anik Ganguly, Bruce Kahn, Leo Parker, John Rose, Vinod Seraphin, Richard
Shusterman, Derik Stenerson, Kevin Tsurutome.
Silverberg/Mansour/Dawson/Hopson 93 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
8 Bibliography
[ICAL] "Internet Calendaring and Scheduling Core Object Specification -
iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet-
drafts/draft-ietf-calsch-ical-00.txt.
[ICMS] "Internet Calendaring Model Specification", Internet-Draft, July
1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-00.txt
[ID-DT] "Date and Time on the Internet", Internet-Draft, December 1996,
http://www.imc.org/draft-newman-datetime.
[ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646",
Internet-Draft, July,1996, ftp://ftp.ietf.org/internet-drafts/draft-
yergeau-utf8-01.txt.
[ISO8601] "Data elements and interchange formats - information
interchange - Representation of dates and times", ISO 8601, 1996-06-15,
+1 (212) 642-4900 for ANSI Sales.
[ITIP-2] "iCalendar Transport-Independent Interoperability Protocol
(iTIP) _ Part Two: Scheduling To-Dos", Internet-Draft, July 1997,
http://www.imc.org/ietf-calsch-itip-part2-00.txt.
[ITIP-3] "iCalendar Transport-Independent Interoperability Protocol
(iTIP) - Part Three: Scheduling Journal Entries", Internet-Draft, July
1997, http://www.imc.org/ietf-calsch-itip-part3-00.txt.
[VCARD] "vCard - The Electronic Business Card Exchange Format - Version
2.1", Versit Consortium, September 18, 1996,
http://www.imc.org/pdi/vcard-21.doc.
[RFC821] Postel, "Simple Mail Transfer Protocol", RFC 821, organization
name, November 1996, http://www.imc.org/rfc2045.
[RFC2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail
Extensions - Part One - Format of Internet Message Bodies", RFC 2045,
Innosoft, First Virtual, November 1996, http://www.imc.org/rfc2045.
[RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail
Extensions - Part Two - Media Types", RFC 2046, Innosoft, First Virtual,
November 1996, http://www.imc.org/rfc2046.
[UNICODE] The Unicode Consortium, "The Unicode Standard -Version 2.0",
Addison-Wesley Developers Press, July 1996. UTF-8 is described in
section A-2.
[US-ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
Silverberg/Mansour/Dawson/Hopson 94 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
9 Authors Addresses
The following address information is provided in a MIME-VCARD,
Electronic Business Card, format.
The authors of this draft are:
BEGIN:VCARD
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613-
3502;USA
TEL;WORK;MSG:+1-919-676-9515
TEL;WORK;FAX:+1-919-676-9564
EMAIL;INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:VCARD
BEGIN:VCARD
FN:Ross Hopson
ORG:On Technology, Inc.
ADR;WORK;POSTAL;PARCEL:Suite 1600;;434 Fayetteville St.
Mall, Two Hannover Square;Raleigh;NC;27601
TEL;WORK;MSG:+1-919-890-4036
TEL;WORK;FAX:+1-919-890-4100
EMAIL;INTERNET:rhopson@on.com
END:VCARD
BEGIN:VCARD
FN:Steve Mansour
ORG:Netscape Communications Corporation
ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain
View;CA;94043;USA
TEL;WORK;MSG:+1-415-937-2378
TEL;WORK;FAX:+1-415-428-4059
EMAIL;INTERNET:sman@netscape.com
END:VCARD
BEGIN:VCARD
FN:Steve Silverberg
ORG:Microsoft Corporation
ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way;
Redmond;WA;98052-6399;USA
TEL;WORK;MSG:+1-206-936-9277
TEL;WORK;FAX:+1-206-936-8019
EMAIL;INTERNET:stevesil@Exchange.Microsoft.com
END:VCARD
The iCalendar Object is a result of the work of the Internet Engineering
Task Force Calendaring and scheduling Working Group. The chairman of
that working group is:
BEGIN:VCARD
FN:Anik Ganguly
ORG:OnTime, Inc.
Silverberg/Mansour/Dawson/Hopson 95 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern
Highway;Southfield;MI;48075;USA
TEL;WORK;MSG:+1-810-559-5955
TEL;WORK;FAX:+1-810-559-5034
EMAIL;INTERNET:anik@ontime.com
END:VCARD
Appendix A. Transport Protocol Considerations
Calendar and scheduling functions are accomplished entirely through
iCalendar objects described in Section 2.1, Application Protocol. The
responsibility of exchanging the iCalendar objects belongs to the
transport. Binding documents for a real-time transport (iRIP) and a
store-and-forward transport (iMIP) are planned by the calsched working
group. Other transports bindings are possible as well. This section
discusses some of the issues that must be addressed in an iTIP binding
document.
The relevant model elements include:
. the User, the person sending the iCalendar Object,
. the Sender, the device used to contact a receiving device, send
commands, and receive replies, and
. the Receiver, the device that accepts commands and sends
replies.
These elements are depicted below. The Sender and receiver can take on
varying roles of CUA and CS as described in [ICMS].
+----------+ +----------+
+----+ | | | |
|User|<->| Sender | iTIP | Receiver |
+----+ | | Commands/Replies | |
| |<====================>| |
| | | | +--------+
| | | |<->|Calendar|
+----------+ +----------+ +--------+
The transport protocol must include methods for categorizing the
authenticity of the User, the Sender, and Receiver. The transport
protocol must also includes method for categorizing the connection type.
Note that secure connection technology such as Secure Socket Layer (SSL)
authenticates the Sender and Receiver and provides secure communication
between them, but does not authenticate the user initiating the
transfer. Also, note that the digital certificate of a user does not
authenticate the Sender nor does it mean that data transmitted between
the Sender and Receiver is private.
The basic steps which a Transport binding must addressed are listed
below.
Silverberg/Mansour/Dawson/Hopson 96 Expires January 1998
Internet Draft iTIP Part 1 - Scheduling Events/BusyTime July 18, 1997
Transport Description IRIP notes IMIP notes
Operational
Phases
CONNECT Establish May include No op
communicati authentication
on with the of the sender
Receiver and receiver
AUTHENTICAT Establish May be May include
E the anonymous, the user's
authenticit clear text digital
y of the login and certificate
user. password, or
SASL [SASL]
RECIPIENT Identify Identifies the Identifies the
the Users whose message
recipients calendar's recipients
of the should receive
iCalendar the iCalendar
object objects
ICALDATA Send an Sends an Sends an
iCalendar iCalendar iCalendar
Object to object object
the
Receiver
DISCONNECT Terminate Disconnect No op
the
connection
A valid binding document must:
. Describe how it will handle each operational phase.
. Provide errors returns for attempts to use unsupported options.
Silverberg/Mansour/Dawson/Hopson 97 Expires January 1998
