Network Working Group F. Dawson, Lotus
INTERNET-DRAFT R. Hopson, ON Technologies
<ietf-calsch-itip-part2-00.txt> S. Mansour, Netscape
Expires in six months from July 18, 1997 S. Silverberg, Microsoft
iCalendar Transport-Independent Interoperability Protocol
(iTIP) Part Two: Scheduling To-Dos
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 for busy time and
the scheduling of events, journals, or journal entries on different
calendaring and scheduling systems. These documents are based on
earlier work documented in the iCalendar format. Because iCalendar
delt mainly with the format of calendaring information and said so
little about the method for conveying scheduling semantics, these
documents add scheduling semantics to the base calendaring
functionality defined in iCalendar.
The initial document specifies the messages for allowing searching
for free or 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. 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).
Dawson/Hopson/Mansour/Silverberg 1 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
The breadth of this document is limited to exchanging only the to-do
type of calendar information. It does not address issues related to
events or journal entries. Instead, the document outlines a model for
calendar exchange that defines both static and dynamic to-do objects.
Static to-do objects are used to transmit to-dos from one entity to
another without the expectation of continuity or referential
integrity with the original item. Dynamic to-do objects are a
superset of static to-do objects and will gracefully degrade to their
static counterparts for clients that only support static to-do
objects.
Dawson/Hopson/Mansour/Silverberg 2 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
Table of Contents:
1. INTRODUCTION........................................................5
1.1 ITIP SCHEDULING TRANSACTIONS.....................................5
2. PROTOCOL MODELS.....................................................6
2.1 APPLICATION PROTOCOL.............................................6
2.1.1 Scheduling Transaction State..................................7
2.2 ADVANCED CALENDARING CONCEPTS....................................8
2.3 CALENDAR ROLES...................................................9
3. APPLICATION PROTOCOL ELEMENTS.......................................9
3.1 ITIP MESSAGE CONFORMANCE........................................10
3.1.1 Restrictions on DTSTART and DUE..............................11
3.2 SUMMARY OF APPLICATION PROTOCOL ELEMENTS........................11
3.2.1 TODO-PUBLISH.................................................11
3.2.2 TODO-REQUEST.................................................14
3.2.3 TODO-REPLY...................................................18
3.2.4 TODO-CANCEL..................................................20
3.2.5 Rescheduling or Changing a To-do.............................22
3.2.6 TODO-RESEND..................................................26
3.3 REQUEST STATUS CODES............................................29
4. EXAMPLES...........................................................31
4.1 PUBLISHED TO-DOS................................................31
4.1.1 A Minimal Published To-Do....................................32
4.1.2 Changing A Published To-Do...................................32
4.1.3 Canceling A Published To-Do..................................33
4.1.4 A Rich Published To-Do.......................................33
4.2 GROUP TO-DO EXAMPLES............................................35
4.2.1 A To-Do Request..............................................36
4.2.2 A To-Do Reply................................................36
4.2.3 Update A To-do...............................................37
4.3 RECURRING TO-DO AND TIME ZONE EXAMPLES..........................37
4.3.1 A Recurring To-do That Spans Timezones.......................37
4.3.2 Creating an Exception to a Recurring To-Do..................39
4.3.3 Modify Exception.............................................40
4.3.4 Cancel an Exception..........................................40
4.3.5 Cancel Recurring To-Do.......................................41
4.3.6 Decline A Previously Accepted Exception......................41
5. APPLICATION PROTOCOL FALLBACKS.....................................42
5.1 ICALENDAR PROFILE TYPES.........................................42
5.2 CALENDAR COMPONENTS.............................................42
5.3 CALENDAR PROPERTIES.............................................43
5.4 COMPONENT PROPERTIES............................................43
5.5 LATENCY ISSUES..................................................45
5.5.1 Cancelation of an Unknown To-do..............................45
5.6 SEQUENCE NUMBER.................................................45
6. SECURITY CONSIDERATIONS............................................45
Dawson/Hopson/Mansour/Silverberg 3 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
7. ACKNOWLEDGMENTS....................................................46
8. BIBLIOGRAPHY.......................................................46
9. AUTHORS ADDRESSES..................................................47
Dawson/Hopson/Mansour/Silverberg 4 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos 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 set of documents is based on the calendaring and scheduling
model specified in [ICSM].
The first document in the set specifies the messages for allowing
searching for free or busy time information and for scheduling
events. This 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 seach for available free or busy time
information and scheduling events, to-dos, or daily journal entries.
1.1 iTIP Scheduling Transactions
The profiles described in section 3 (Application Protocol Elements)
may be considered usage profiles of the [ICAL] and is designed
specifically for the exchange of calendaring information between
scheduling applications.
To-do Publication
Publish a to-do;
Change a published to-do;
Cancel a published to-do.
Group To-dos
Request that a to-do be assigned to one or more recipients;
Reply to an existing to-do request to accept, decline, or
indicate completion of the to-do request;
Allow the organizer of a to-do to cancel the to-do;
Allow the organizer of a to-do to replace the original to-do
definition, as when a to-do description is clarified or the
attendee assignment information is updated;
Allow an attendee to request a resend of the current
description for an existing request.
Recurring To-dos and Timezones
Dawson/Hopson/Mansour/Silverberg 5 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
Support scheduling a to-do between individuals in different
time zones;
Support for time zones;
Support for DST rules;
Create a recurring to-do request with exception dates
2. Protocol Models
The protocol model for this part of iTIP is intended to be the same
as that described in iTIP Part 1. It is repeated here for clarity
when reading this document alone.
There are two distinct protocols that comprise iTIP: an Application
Protocol and a Transport Protocol. The Application Protocol defines
the content of the iCalendar objects sent between a sender and a
receiver in order to accomplish the various iTIP scheduling
transactions (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 of [ITIP-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 may utilize either the
binding for the store-and-forward transport, the real time transport,
or both. The iTIP could also 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 originator-based (organizer
or owner roles for a request). That is, the originator of a request
sends it out to one or more invitees. The invitees reply back to the
Dawson/Hopson/Mansour/Silverberg 6 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
originator. The originator maintains the status of the event. Only
the originator can modify or cancel the request.
The data sources for the protocol are the Calendar Users as defined
in [ICMS]. Examples of these users are the originator (i.e.,
organizer or owner) and attendees of an iCalendar to-do. The data
objects are the iCalendar objects that are exchanged between Calendar
Users.
2.1.1 Scheduling Transaction State
The state of the to-do scheduling transaction is described by the
STATUS and ATTENDEE properties in the to-do calendar component.
If there are no attendees in the calendar component, then this
implies the publish - state STATUS.
The state of a to-do 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 to-do. When an originator sends out the
to-do request, it's 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. When the attendee completes the to-do,
then the status is changed to COMPLETED. These changes in the
attendee status for the to-do are effected by the attendee sending
the originator a TODO-REPLY message with their updated status.
The general status of the to-do is reflected by the STATUS property.
The to-do STATUS property is controlled by the originator. There is
no default status. Initially, the originator should either set the
status to TENTATIVE or CONFIRMED. The originator can also set the
status to CANCELLED by sending a TODO-CANCEL message to the
attendees. The status is set to COMPLETED when all the attendees for
the to-do request have indicated their completion of the assignment
by sending the originator a TODO-REPLY message with their status set
to COMPLETED.
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.
Dawson/Hopson/Mansour/Silverberg 7 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
+===========================+==========================
| Owner / Originator | Attendee / Recipient |
+===========================+=========================+
| TODO-PUBLISH -----------------------------------> |
| State=CONFIRMED |
+=====================================================+
| TODO-REQUEST -----------------------------------> |
| State=CONFIRMED | TENTATIVE |
| Attendee Status=NEEDS ACTION |
| |
| <------------------------------------- TODO-REPLY |
| State=As specified in the TODO-REQUEST message |
| Attendee Status=ACCEPTED | DECLINED | COMPLETED |
+=====================================================+
| TODO-CANCEL -----------------------------------> |
| State=CANCELLED |
| Attendee Status=As specified in the TODO-REPLY |
+=====================================================+
| TODO-REQUEST -----------------------------------> |
| (A rescheduled or redefined to-do request) |
| State=CONFIRMED | TENTATIVE |
| Attendee Status=As defined in previous TODO- |
| REPLY message for this to-do |
+=====================================================+
| <-------------------------------------TODO-RESEND |
| State=As specified in the TODO-REQUEST message |
| Attendee Status=As specified in the TODO-REPLY |
+=====================================================+
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 a to-do
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
to-dos.
The message format is designed to be used with either a MIME
electronic messaging transport, real time protocols, and other
Internet and non-Internet 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 a to-do to change or cancel the original request. The
elements of the protocol also include the notion of user roles.
Dawson/Hopson/Mansour/Silverberg 8 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
2.3 Calendar Roles
Roles are a behavior or set of activities performed by particular
groups of users or agents at a particular time given the state of the
application. This specification describes 3 roles that determine a
range of actions and responsibilities specific to each role. When
scheduling a to-do with one or more individuals, there are 3 roles:
OWNER, ORGANIZER and ATTENDEE. The OWNER is generally the originator
of the to-do request. The OWNER sends the to-do request and receives
responses from the ATTENDEES. The OWNER is the effective owner of the
to-do. There are scenarios where the OWNER has an agent or associate
who acts on the OWNER's behalf, as is the case when your an assistant
makes assignments for you. 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 entities for this to-do.
Role Description
Organi The organizer is the calendar user that sends
zer and manages the to-do --- meaning responses
are directed at the organizer. In most cases
the organizer is also the owner, but in cases
where the owner has the organizer act on it's
behalf, the organizer becomes a proxy for the
owner. The organizer in this case would place
the to-do on the calendar of the owner.
Owner The owner generally controls direct
manipulation of the to-do. The owner can make
unilateral changes to the to-do while the
attendees can reply back to the owner. The
owner is usually the organizer, but in some
cases an agent or associate will act on
behalf of the owner and organize the to-do
and assignment logistics.
Attend Attendees are those recipients who are
ees assigned the group to-do. When an attendee
responds to the request, the attendee's
status property is set to either accept,
decline, tentative, or completed
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
Dawson/Hopson/Mansour/Silverberg 9 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
following describes the various [ICAL] profile types supported in
this specification.
Profile Type Description
TODO-PUBLISH Post notification of a to-do. Used
primarily as a method of advertising the
existence of a to-do. The ATTENDEES
property is not included and no
interaction is expected.
TODO-REQUEST Make a to-do assignment. This is an
explicit assignment of a to-do to one or
more attendees. To-do requests are also
used to update or change an existing to-
do description. Clients that cannot
handle TODO-REQUEST messages can degrade
the to-do to view it as a TODO-PUBLISH.
TODO-REPLY Reply to a to-do request. This includes
"ACCEPT", "TENTATIVE", "DECLINE" and
"COMPLETED".
TODO-CANCEL Cancel an existing to-do request. Uses
the UID to identify the to-do to be
canceled.
TODO-RESEND Resend an existing to-do request. Uses
the UID to identify the to-do to be
resend.
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 to-dos (where posting
means to local calendar). Therefore, profiles such as TODO-REQUEST
will contain an exact superset of the TODO-PUBLISH property set such
that a client that supported TODO-PUBLISH could still read a TODO-
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.
Dawson/Hopson/Mansour/Silverberg 10 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
3.1.1 Restrictions on DTSTART and DUE
The DTSTART property must always be specified. This specifies the
date/time that the to-do is to first be displayed. The DUE property
may be specified. This specifies the date/time that the to-do is
assigned to be completed. If the DUE property is missing, then the
implicit due date/time for the to-do is to be set to the current
date, until the to-do is completed. A to-do request containing DUE
without a DTSTART is not allowed. The DTSTART and the DUE properties
may have the same value. If the due date/time is known, the DUE
property should be specified. The DURATION property 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 TODO-PUBLISH
The TODO-PUBLISH is somewhat unique in this document in that it has
no response scheduling message associated with it. Instead, it is
simply a to-do that can be added by a calendar user agent to a
calendar as a static to-do entry. There is no defined response to the
originator of a TODO-PUBLISH message. It's expected usage is for
publication of to-dos such as those that might be published on a
website or Internet calendar. The TODO-PUBLISH is simply a MIME
encapsulated file that can be referenced and opened by the
appropriate handler for a TEXT/CALENDAR MIME content type and EVENT-
PUBLISH profile type.
TODO-PUBLISH
Calendar Properties
COMMENT
Not Required
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required, "TODO-PUBLISH"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
COMMENT
Not Required
Dawson/Hopson/Mansour/Silverberg 11 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
CREATED
Not Required
DAYLIGHT
Not Required
DTSTART
Required
DTSTART
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
Required
Event Component Properties
To-do component is excluded from
this message type.
To-do Component Properties
ATTACH
Not Required, "VALUE=URL" only.
ATTENDEE
Not Required
CATEGORIES
Not Required
CLASS
Not Required
COMMENT
Not Required
CREATED
Not Required
COMPLETED
Not Required
DESCRIPTION
Required, Value may be NULL
text.
DUE
Not Required
DURATION
Excluded
DTEND
Excluded
Dawson/Hopson/Mansour/Silverberg 12 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
DTSTAMP
Required
DTSTART
Required
EXDATE
Not Required
EXRULE
Not Required
LAST-MODIFIED
Not Required
LOCATION
Not Required
PRIORITY
Not Required
RELATED-TO
Not Required
REQUEST-STATUS
Excluded
RDATE
Not Required.
RRULE
Not Required.
RESOURCES
Not Required
RESPONSE-SEQUENCE
Excluded
SEQUENCE
Required, if not zero.
STATUS
Not Required.
SUMMARY
Not Required. May be NULL text.
TRANSP
Excluded
URL
Not Required
UID
Required
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
ATTACH
Not Required
CATEGORIES
Required, If an alarm is
specified
COMMENT
Not Required
CREATED
Not Required
Dawson/Hopson/Mansour/Silverberg 13 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
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
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 Not Required.
3.2.2 TODO-REQUEST
The TODO-REQUEST is used to both describe a to-do and assign the to-
do to one or more attendees. When a TODO-REQUEST is received by a
user it should be responded to with a TODO-REPLY.
TODO-REQUEST
Calendar Properties
COMMENT
Not Required
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"TODO-REQUEST"
Dawson/Hopson/Mansour/Silverberg 14 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
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
To-do component is excluded
from this message type.
To-do Component Properties
ATTACH
Not Required, "VALUE=URL"
only.
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
COMMENT
Not Required
CREATED
Not Required
COMPLETED
Not Required
Dawson/Hopson/Mansour/Silverberg 15 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
DESCRIPTION
Required, Value may be NULL
text.
DUE
Not Required
DURATION
Excluded
DTEND
Excluded
DTSTAMP
Required
DTSTART
Required
EXDATE
Not Required.
EXRULE
Not Required.
LAST-MODIFIED
Not Required
LOCATION
Not Required
PRIORITY
Not Required
RELATED-TO
Not Required
REQUEST-REPLY
Excluded
RDATE
Not Required.
RRULE
Not Required.
RESOURCES
Not Required
RESPONSE-SEQUENCE
Excluded
SEQUENCE
Required, If not zero.
STATUS
Not Required, Value only one
of TENTATIVE | ACCEPTED |
CANCELLED. This property is
used by the originator to
indicate the consensus for the
to-do, not a status on any of
the attendees.
SUMMARY
Not Required, May be NULL
text.
TRANSP
Excluded
URL
Not Required
Dawson/Hopson/Mansour/Silverberg 16 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
UID
Required, Must be maintained
by the recipients.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
ATTACH
Not Required
CATEGORIES
Required, If an alarm is
specified
COMMENT
Not Required
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
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 Not Required.
Dawson/Hopson/Mansour/Silverberg 17 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
3.2.3 TODO-REPLY
The TODO-REPLY is used to by the attendees to reply to the originator
of the to-do request with their status. The attendees can indicate
their status is a TENTATIVE acceptance, that they have ACCEPTED the
assignment, that they DECLINED the assignment or that they have
COMPLETED the assignment. Once an attendee has replied to the
request, they can subsequently reply with a different value.
TODO-REPLY
Calendar Properties
COMMENT
Not Required
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"TODO-REPLY"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
Timezone component is excluded
from this message type.
Event Component Properties
Event component is excluded
from this message type.
To-do 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 a comment
from the recipient to the
originator about the reply.
For example, "I am too busy to
accept this assignment."
Dawson/Hopson/Mansour/Silverberg 18 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
CREATED
Excluded
COMPLETED
Not Required
DESCRIPTION
Excluded
DUE
Excluded
DURATION
Excluded
DTEND
Excluded
DTSTAMP
Required
DTSTART
Excluded
EXDATE
Not Required. Specifies the
dates that are exceptions to
the status update.
EXRULE
Not Required. Specifies the
rule that defines the
exceptions to the status
update.
LAST-MODIFIED
Excluded
LOCATION
Excluded
PRIORITY
Excluded
RELATED-TO
Excluded
REQUEST-STATUS
Not Required. 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.
Dawson/Hopson/Mansour/Silverberg 19 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
SUMMARY
Excluded
TRANSP
Excluded
URL
Excluded
UID
Required, Must be the UID of
the EVENT-REQUEST associate
with the reply.
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 Not Required.
3.2.4 TODO-CANCEL
The TODO-CANCEL is used to by the originator of the to-do request to
convey a cancellation notice of the to-do to the attendees. The
message is only sent by the to-do OWNER or ORGANIZER to the
recipients of the original to-do request.
TODO-CANCEL
Calendar Properties
COMMENT
Not Required
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"TODO-CANCEL"
PROFILE-VERSION
Required, Value must be "1.0".
Dawson/Hopson/Mansour/Silverberg 20 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
Timezone Component Properties
Timezone component is excluded
from this message type.
Event Component Properties
Event component is excluded
from this message type.
To-do Component Properties
ATTACH
Excluded
ATTENDEE
Excluded
CATEGORIES
Excluded
CLASS
Excluded
CREATED
Excluded
COMMENT
Not Required, Text value.
Provides a comment from the
originator to the attendees
concerning the cancellation
notice.
COMPLETED
Excluded
DESCRIPTION
Excluded
DUE
Excluded
DURATION
Excluded
DTEND
Excluded
DTSTAMP
Excluded
DTSTART
Excluded
EXDATE
Excluded
EXRULE
Excluded
LAST-MODIFIED
Excluded
LOCATION
Excluded
PRIORITY
Excluded
RELATED-TO
Excluded
Dawson/Hopson/Mansour/Silverberg 21 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
REQUEST-STATUS
Excluded
RDATE
Excluded
RRULE
Excluded
RESOURCES
Excluded
RESPONSE-SEQUENCE
Excluded
SEQUENCE
Required, if not zero. Is not
incremented by this action.
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.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Properties
Alarm component is excluded
from this message type.
Freebusy Protperties
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.5 Rescheduling or Changing a To-do
When an owner/organizer desires to reschedule or change some detail
of one of their existing to-do requests, they effect this change by
conveying a new to-do request with the same UID and an incremented
Dawson/Hopson/Mansour/Silverberg 22 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
sequence number. The receiving client must correlate the request to
their existing to-dos and check the sequence number in order to
realize that the request is actually a replacement for the existing
to-do. Individual "A" sends a to-do request to "B" and "C". "B"
accepts the to-do and "C" declines and includes text in the comments
property proposing a more appropriate due date. "A" sends "B" and "C"
another to-do request using the same UID and a sequence number one
greater than the original request. "B" should infer that the to-do
request message is actually a replacement for the existing to-do.
Replacing a to-do request is predicated on using the same UID,
incrementing the sequence number and replacing the changed calendar
properties.
TODO-REQUEST (replacing an existing to-do description)
Calendar Properties
COMMENT
Not Required
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"TODO-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
Dawson/Hopson/Mansour/Silverberg 23 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
TZTRANS
Not Required
Event Component Properties
Event component is excluded
from this message type.
To-do Component Properties
ATTACH
Not Required, "VALUE=URL"
only.
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
COMMENT
Not Required
CREATED
Not Required
COMPLETED
Excluded
DESCRIPTION
Required, Value may be NULL
text.
DUE
Not Required, must be after or
the same as the DTSTART
date/time.
DURATION
Excluded
DTEND
Excluded
DTSTAMP
Required
DTSTART
Required
EXDATE
Not Required.
EXRULE
Not Required.
LAST-MODIFIED
Not Required
LOCATION
Not Required
PRIORITY
Not Required
Dawson/Hopson/Mansour/Silverberg 24 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
RELATED-TO
Not Required
REQUEST-STATUS
Excluded
RDATE
Not Required
RRULE
Not Required
RESOURCES
Not Required
RESPONSE-SEQUENCE
Excluded
SEQUENCE
Must be greater than 0 and
should be monotomically
incremented for each request
STATUS
Not Required, Value only one
of TENTATIVE | CONFIRMED |
CANCELLED. This property is
used by the originator to
indicate the consensus for the
to-do, 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
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
Dawson/Hopson/Mansour/Silverberg 25 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos 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
Freebusy Component 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 Not Required.
3.2.6 TODO-RESEND
The TODO-RESEND is used by attendees to request the latest version of
a TODO-REQUEST. By issuing an TODO-RESEND, with the appropriate UID
and optionally a RECURRENCE-ID, the organizer's CUA should respond
with the latest version of the to-do. This message type is intended
to be machine processed.
TODO-RESEND
Calendar Properties
COMMENT
Not Required
GEO
Not Required
PRODID
Required
VERSION
Required, Value must be "2.0".
PROFILE
Required,"TODO-RESEND"
PROFILE-VERSION
Required, Value must be "1.0".
Timezone Component Properties
Dawson/Hopson/Mansour/Silverberg 26 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
Timezone component is excluded
from this message type.
Event Component Properties
Event component is excluded
from this message type.
To-do Component Properties
ATTACH
Excluded
ATTENDEE
Excluded
CATEGORIES
Excluded
CLASS
Excluded
CREATED
Excluded
COMMENT
Not Required, Text value.
Provides a comment from the
attendee to the organizer
concerning the resend request.
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
RELATED-TO
Excluded
REQUEST-STATUS
Excluded
Dawson/Hopson/Mansour/Silverberg 27 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
RDATE
Excluded
RRULE
Excluded
RECURRENCE-ID
Not Required. If the attendee
wishes to receive an updated
instance of a recurring to-do,
then the RECURRENCE-ID can be
included and only the specific
instance will be returned.
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, Must be the UID of
the original EVENT-REQUEST
associated with the
cancellation notice.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Properties
Alarm component is excluded
from this message type.
Freebusy Protperties
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.
Dawson/Hopson/Mansour/Silverberg 28 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
3.3 Request Status Codes
The following is a list of possible return status codes values:
Short Longer Return Status Offending Data
Return Description
Status
Code
200
Success. None.
201
Success, but fallback Property name and
taken on one or more value may be
property values. specified.
202
Success, invalid Property name may be
property ignored. specified.
203
Success, invalid Property parameter
property parameter name and value may be
ignored. specified.
204
Success, unknown non- Non-standard property
standard property name may be
ignored. specified.
205
Success, unknown non- Property and non-
standard property value standard value may be
ignored. specified.
206
Success, invalid Calendar component
calendar component sentinel (e.g.,
ignored. "BEGIN:ALARM") may be
specified.
207
Success, request Original and
forwarded to calendar forwarded RFC822
user. addresses may be
specified.
208
Success, repeating event RRULE or RDATE
ignored. Scheduled as a property name and
single event. value may be
specified.
209
Success, truncated end DTEND property value
date/time to date may be specified.
boundary.
210
Success, repeating to-do RRULE or RDATE
ignored. Scheduled as a property name and
Dawson/Hopson/Mansour/Silverberg 29 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
single to-do. value may be
specified.
300
Invalid property name. Property name may be
specified.
301
Invalid property value. Property name and
value may be
specified.
302
Invalid property Property parameter
parameter. name and value may be
specified.
303
Invalid property Property parameter
parameter value. name and value may be
specified.
304
Invalid calendar Calendar component
component sequence. sentinel may be
specified (e.g.,
BEGIN:TIMEZONE).
305
Invalid date or time. Date/time value(s)
may be specified.
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 None.
large.
400
Event conflict. DTSTART and DTEND
Date/time is busy. property name and
values may be
specified.
500
Request not supported. Profile property
value may be
specified.
Dawson/Hopson/Mansour/Silverberg 30 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
501
Service unavailable. ATTENDEE property
value may be
specified.
502
Invalid calendar ATTENDEE property
service. value may be
specified.
503
No scheduling support ATTENDEE property
for user. value may be
specified.
4. Examples
4.1 Published To-Dos
In the calendaring and scheduling context, publication refers to the
one way transfer of to-do information. Consumers of published to-dos
simply incorporate the to-do into a calendar. No reply is expected.
Individual "A" publishes a to-do. Individual "B" reads the to-do and
incorporates it into their calendar. To-dos can be published in
several ways including: embedding the to-do as an object in a web
page, e-mailing the to-do to a distribution list, and posting the to-
do to a newsgroup.
The table below illustrates the sequence of to-dos between the
publisher and the consumers of a published to-do.
Action Organizer Attendee
Publish a to-do "A" sends or posts a
TODO-PUBLISH message
"B" reads the to-
do publication
Publish an updated "A" sends or posts a
to-do TODO-PUBLISH message
"B" reads the
updated to-do
publication
Cancel a published "A" sends or posts a
to-do toDO-CANCEL message
"B" reads the
canceled to-do
Dawson/Hopson/Mansour/Silverberg 31 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
publication
4.1.1 A Minimal Published To-Do
The iCalendar Object below describes a single to-do is due on October
1, 1997 at 20:00 UTC. This to-do contains the minimum set of
properties for an iTIP to-do component.
BEGIN:VCALENDAR
PROFILE:TODO-PUBLISH
PROFILE-VERSION:1.0
PRODID:-//ACME/DesktopCalendar//EN
VERSION:2.0
BEGIN:VTODO
DUE:19971001T200000Z
SUMMARY:Book Report on Fiction Novel
UID:0981234-1234234-2300
DTSTAMP:19970717T200000Z
END:VTODO
END:VCALENDAR
4.1.2 Changing A Published To-Do
The iCalendar Object below describes an update to the to-do described
in 4.1.1, the due date has been changed, a start time has been added,
and the sequence number has been adjusted.
BEGIN:VCALENDAR
PROFILE:TODO-PUBLISH
PROFILE-VERSION:1.0
VERSION:2.0
PRODID:-//ACME/DesktopCalendar//EN
BEGIN:VTODO
DTSTART:19970901T210000Z
DUE:19971005T200000Z
SEQUENCE:2
UID:0981234-1234234-2300
SUMMARY:Book Report on Fiction Novel
DTSTAMP:19970717T200000Z
STATUS:NEEDS-ACTION
END:VTODO
END:VCALENDAR
To identify the to-do the client uses the UID. The SEQUENCE property
indicates that this is the second change to the to-do. To-dos with
sequence numbers 0 and 1 are superseded by this to-do.
The SEQUENCE property provides a reliable way to distinguish
different versions of the same to-do. Each time a to-do is published,
its sequence number is incremented. If a client receives a to-do with
a sequence number 5 and finds it has the same to-do with sequence
number 2, the to-do should be updated. However, if the client
Dawson/Hopson/Mansour/Silverberg 32 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
received a to-do with sequence number 2 and finds it already has
sequence number 5 of the same to-do, the to-do should not be updated.
4.1.3 Canceling A Published To-Do
The iCalendar Object below cancels the to-do described in 4.1.1. This
cancels the to-do with SEQUENCE numbers 0, 1, and 2.
BEGIN:VCALENDAR
PROFILE:TODO-CANCEL
PROFILE-VERSION:1.0
VERSION:2.0
PRODID:-//ACME/DesktopCalendar//EN
BEGIN:VTODO
COMMENT:As discussed in class, you are all off the hook!
SEQUENCE:2
UID:0981234-1234234-2300
STATUS:CANCELLED
DTSTAMP:19970717T200000Z
END:VTODO
END:VCALENDAR
4.1.4 A Rich Published To-Do
This example describes the same to-do 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:TODO-PUBLISH
PROFILE-VERSION:1.0
CALSCALE:GREGORIAN
SOURCE:http://www.acmeu.edu/courses/eng-lit-101/Fall97-to-dos.or4
Dawson/Hopson/Mansour/Silverberg 33 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
NAME:English Literature 101 Course Calendar
VERSION:2.0
BEGIN:VTODO
ATTACH:http://www.midwaystadium.com/courses/eng-lit-101/
CATEGORIES:EDUCATION;COURSE-ASSIGNMENT
CLASS:PRIVATE
CREATED:19970415T194319Z
DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:Book Report =
1=0A=0D=
Fiction=0A=0D=
Dr. Ling must approve the book you choose=0A=0D=
book report structure can be found on:=
http://www.acmeu.com/courses/eng-lit-101/bookreports.html
DTSTART:19970901T210000Z
DUE:19971005T200000Z
COMPLETED:19971005T150000Z
DTSTAMP:19970717T200000Z
SEQUENCE:2
UID:0981234-1234234-2300
LAST-MODIFIED:19971005T132421Z
RESOURCES:COMPUTER,PRINTER
LOCATION;VALUE=URL:http://www.acmeu.com/campusmaps/haaghall.html
PRIORITY:2
SEQUENCE:3
SUMMARY:Book Report on Fiction Novel
UID:0981234-1234234-2300
STATUS:NEEDS-ACTION
RELATED-TO:0981234-1234234-1400
BEGIN:VALARM
DTSTART:19970910T190000Z
REPEAT:2
DURATION:PT2H
CATEGORIES:DISPLAY,AUDIO
DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:Book report
rough draft
END:VALARM
BEGIN:VALARM
DTSTART:19970930T153000
CATEGORIES:DISPLAY,AUDIO
DESCRIPTION:You should be reviewing your final book report draft.
END:VALARM
END:VTODO
END:VCALENDAR
The CLASS property is specified, though it is not really needed here.
Since this is a published to-do, a program that displays it need not
apply any content filtering based on the CLASS attribute. If this to-
do is copied into a users calendar, the CLASS would be included as
Dawson/Hopson/Mansour/Silverberg 34 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
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 to-do or
event. The handling of this property is application dependent.
VTIMEZONE components are discussed in detail in iTIP Part 1.
The sequence number 3 indicates that this to-do supersedes versions
0, 1, and 2.
4.2 Group To-Do Examples
Group to-dos are distinguished from published to-dos in that there is
interaction between the attendees with respect to the to-do.
Individual "A" creates a group task in which individuals "A", "B",
"C" and "D" will participate. Individual "B" confirms acceptance of
the task. Individual "C" declines the task. Individual "D"
tentatively accepts the task. The following table illustrates the
sequence of messages that would be exchanged between these
individuals. The table below illustrates the message flow.
Action Organizer Attendee
Initiate a "A" sends TODO-
to-do REQUEST message
request to "B", "C", and
"D"
Accept the "B" sends TODO-
to-do REPLY message to
request "A" with its
ATTENDEE/STATUS
property parameter
set to "ACCEPTED"
Decline the "C" sends TODO-
to-do REPLY message to
request "A" with its
ATTENDEE/STATUS
property parameter
set to "DECLINED"
Tentatively "D" sends TODO-
accept the REPLY message to
to-do "A" with its
request ATTENEE/STATUS
property parameter
set to "TENTATIVE"
Confirm to- "A" sends TODO-
Dawson/Hopson/Mansour/Silverberg 35 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
do status REQUEST message
with to "B" and "C"
attendees with current
information for
to-do. SEQUENCE
property is "1".
4.2.1 A To-Do Request
A sample to-do request that "A" sends to "B", "C", and "D".
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:TO-DO-REQUEST
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VTODO
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
DTSTART:19970701T100000-0700
DUE:19970722T100000-0700
SUMMARY:Create the requirements document
UID:www.acme.com-873970198738777-00
SEQUENCE:0
DTSTAMP:19970717T200000Z
STATUS:NEEDS-ACTION
END:VTODO
END:VCALENDAR
Note that the conference room does not have a valid e-mail address.
4.2.2 A To-Do Reply
Attendee "B" accepts the meeting.
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:TODO-REPLY
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VTODO
ATTENDEE;STATUS=ACCEPTED:B@acme.com
UID:www.acme.com-873970198738777-00
COMMENT:I'll send you my input by e-mail
SEQUENCE:0
RESPONSE-SEQUENCE:0
DTSTAMP:19970717T200000Z
REQUEST-STATUS:0;Success
END:VTODO
Dawson/Hopson/Mansour/Silverberg 36 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
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 A To-do
The to-do 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
PROFILE:TODO-REQUEST
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VTO-DO
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
DTSTART:19970701T110000-0700
DUE:19970722T100000-0700
COMPLETED:19970720T090000-0700
DTSTAMP:19970717T200000Z
STATUS:COMPLETED
SUMMARY:Create the requirements document
UID:www.acme.com-873970198738777
SEQUENCE:1
END:VTODO
END:VCALENDAR
4.3 Recurring To-do and Time Zone Examples
4.3.1 A Recurring To-do That Spans Timezones
This to-do describes a weekly status report. 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
Dawson/Hopson/Mansour/Silverberg 37 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
BEGIN:VTIMEZONE
DAYLIGHT:FALSE
DTSTART:19970126T000000
RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY
TZNAME:PST
TZOFFSET:-0800
TTRANS:020000
END:VTIMEZONE
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:TODO-REQUEST
VERSION:2.0
BEGIN:VTODO
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
DTSTART:19970701T140000
DUE:19970701T150000
RRULE:INTERVAL=20;WKST=SU;BYDAY=TU;FREQ=WEEKLY
RDATE:19970910T140000
EXDATE:19970909T140000
EXDATE:19971028T150000
SUMMARY:Weekly Status Report
UID:www.acme.com-873970198738777
SEQUENCE:0
DTSTAMP:19970601T200000Z
STATUS:NEEDS-ACTION
END:VTODO
END:VCALENDAR
Timezone components should appear in an iCalendar Object containing
recurring to-dos. This is especially important if a recurring to-do
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 to-do 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 first instance of the to-do 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
Dawson/Hopson/Mansour/Silverberg 38 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
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 to-do 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:
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.3.2 Creating an Exception to a Recurring To-Do
The following example illustrates a scenario where a to-do organizer
changes an instance of an existing recurring to-do. In this case the
organizer is changing the start and end time.
Original Request:
BEGIN:VCALENDAR
PROFILE:TODO-REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VTODO
CREATED:19970526T083000
UID:guid-1.host1.com-001
SEQUENCE:0
RRULE:BYMONTHDAY=1;FREQ=MONTHLY
ATTENDEE;ROLE=ORGANIZER;STATUS=ACCEPTED:Sman@netscape.com
ATTENDEE;RSVP=YES:fdawson@earthlink.net
ATTENDEE;RSVP=YES:Deriks@Microsoft.com
ATTENDEE;RSVP=YES:Alecd@Microsoft.com
DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC
SUMMARY:Merge document updates
DTSTART:19970601T210000Z
DUE:19970601T220000Z
LOCATION:Conference Call
DTSTAMP:19970601T200000Z
STATUS:NEEDS-ACTION
END:VTODO
END:VCALENDAR
Dawson/Hopson/Mansour/Silverberg 39 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
To-do Request to change a time and create an exception:
BEGIN:VCALENDAR
PROFILE:TODO-REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VTODO
UID:guid-1.host1.com-001
SEQUENCE:1
RECURRENCE-ID:19970701T210000Z
DTSTART:19970703T210000Z
DUE:19970703T220000Z
DTSTAMP:19970701T200000Z
END:VTODO
END:VCALENDAR
4.3.3 Modify Exception
In this example the organizer has already created an exception and
now wishes to make additional property modification. The organizer
must use both the RECURRENCE-ID and UID to reference the exception.
BEGIN:VCALENDAR
PROFILE:TODO-REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VTODO
UID:guid-1.host1.com-001
SEQUENCE:2
RECURRENCE-ID:19970701T210000Z
ATTENDEE;EXPECT=REQUEST:Sman@netscape.com
ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net
ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com
ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com
ATTENDEE;EXPECT=REQUEST:RHopson@dev.davinci.com
DESCRIPTION:Emergency Meeting
CLASS:Private
DTSTAMP:19970701T200000Z
STATUS:NEEDS-ACTION
END:VTODO
END:VCALENDAR
This example changes the specific instance properties without changing
the recurring meeting parent.
4.3.4 Cancel an Exception
In the following example, the organizer has created an exception as
in 4.3.2 and now wishes to cancel it. In this case a TODO-CANCEL is
sent with the specific RECURRENCE-ID and UID of the exception.
Dawson/Hopson/Mansour/Silverberg 40 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
BEGIN:VCALENDAR
PROFILE:TODO-CANCEL
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VTODO
UID:guid-1.host1.com-001
RECURRENCE-ID:19970701T210000Z
SEQUENCE:2
DTSTAMP:19970701T200000Z
STATUS:CANCELLED
END:VTODO
END:VCALENDAR
4.3.5 Cancel Recurring To-Do
In this example the organizer wishes to cancel the entire recurring
to-do and any child exceptions.
BEGIN:VCALENDAR
PROFILE:TODO-CANCEL
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VTODO
UID:guid-1.host1.com-001
SEQUENCE:2
DTSTAMP:19970701T200000Z
STATUS:CANCELLED
END:VTODO
END:VCALENDAR
4.3.6 Decline A Previously Accepted Exception
In this example a recipient has accepted a TODO-REQUEST which is
actually an exception. The recipient now wishes to decline after
previously accepting
Recipient initially accepts to-do request:
BEGIN:VCALENDAR
PROFILE:TODO-REPLY
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO
SEQUENCE:1
RESPONSE-SEQUENCE:1
UID:guid-1.host1.com-001
RECURRENCE-ID:19970701T210000Z
ATTENDEE;STATUS=CONFIRMED:Deriks@Microsoft.com
REQUEST-STATUS:0;Success
DTSTAMP:19970701T200000Z
RESPONSE-SEQUENCE:0
END:VTODO
Dawson/Hopson/Mansour/Silverberg 41 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
END:VCALENDAR
Recipient later wishes to decline the request to a recurring
exception:
BEGIN:VCALENDAR
PROFILE:TODO-REPLY
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VTODO
SEQUENCE:0
RESPONSE-SEQUENCE:1
UID:guid-1.host1.com
RECURRENCE-ID:19970701T210000Z
ATTENDEE;STATUS=Declined:Deriks@Microsoft.com
REQUEST-STATUS:0;Success
DTSTAMP:19970702T200000Z
END:VTODO
END:VCALENDAR
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 ICalendar Profile Types
Profile Fallback
TODO-PUBLISH Required.
TODO-CANCEL Required.
TODO-REQUEST TODO-PUBLISH
TODO-REPLY Required.
5.2 Calendar Components
Component Fallback
VALARM Reply with Not Supported.
Dawson/Hopson/Mansour/Silverberg 42 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
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- Assume "1.0".
VERSION
SOURCE Ignore
NAME Ignore.
VERSION Assume "2.0".
5.4 Component Properties
Property Fallback
ATTACH Ignore.
ATTENDEE Required if TODO-REQUEST is not
implemented; otherwise ignore.
CATEGORIES Ignore.
CLASS Ignore.
COMMENT Ignore.
COMPLETED Required.
Dawson/Hopson/Mansour/Silverberg 43 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
CREATED Ignore.
DAYLIGHT Required if VTIMEZONE is implemented;
otherwise ignore.
DESCRIPTION Required.
DUE Required.
DURATION Ignore. Reply with Not Supported.
DTSTART Required.
EXDATE Ignore. Reply with Not Supported.
EXRULE Ignore. Reply with Not Supported.
LAST- Ignore.
MODIFIED
LOCATION Ignore.
PRIORITY Required.
RELATED-TO Ignore.
RDATE Ignore. If implemented, VTIMEZONE must
also be implemented.
RRULE Ignore. The first instance occurs on
the DTStart property.
RESOURCES Ignore.
RESPONSE- Required.
SEQUENCE
SEQUENCE Required.
STATUS Required.
SUMMARY Ignore.
TRANSP Required if FREEBUSY is implemented;
otherwise Ignore.
TZNAME Required if VTIMEZONE is implemented;
otherwise Ignore.
TZOFFSET Required if VTIMEZONE is implemented;
otherwise Ignore.
Dawson/Hopson/Mansour/Silverberg 44 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
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 requests to
arrive out of sequence. That is, an implementation may receive a
TODO-CANCEL notification prior to receiving the original to-do
request. This section discusses a few of these scenarios.
5.5.1 Cancelation of an Unknown To-do.
When a TODO-CANCEL request is received before the original TODO-
REQUEST the calendar will be unable to correlate the UID of the
cancellation with an existing to-do. 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.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 (for Events)
LOCATION
DUE
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.
Dawson/Hopson/Mansour/Silverberg 45 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
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.
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.
8. Bibliography
[ID-DT] "Date and Time on the Internet", Internet-Draft, December
1996, http://www.imc.org/draft-newman-datetime.
[ICAL] "Internet Calendaring and Scheduling Core Object Specification
- iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet-
drafts/draft-ietf-calsch-ical-02.txt.
[ICMS] "Internet Calendaring Model Specification", Internet-Draft,
July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-
00.txt.
[ITIP-1] "iCalendar Transport-Independent Interoperability Protocol
(iTIP) - Part 1: Scheduling Events and Busytime", Internet-Draft,
July 1997, http://www.imc.org/draft-ietf-calsch-itip-part1-00.txt.
[ITIP-2] "iCalendar Transport-Independent Interoperability Protocol
(iTIP) - Part 2: Scheduling To-dos", Internet-Draft, July 1997,
http://www.imc.org/draft-ietf-calsch-itip-part2-00.txt
[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.
[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.txt.
[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.txt.
[UNICODE] The Unicode Consortium, "The Unicode Standard -Version
2.0", Addison-Wesley Developers Press, July 1996. UTF-8 is described
in section A-2.
Dawson/Hopson/Mansour/Silverberg 46 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
[US-ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
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
Dawson/Hopson/Mansour/Silverberg 47 Expires January 1998
Internet Draft iTIP Part Two - Scheduling To-dos July 18, 1997
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.
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
Dawson/Hopson/Mansour/Silverberg 48 Expires January 1998
Datatracker
Report a datatracker bug
draft-ietf-calsch-itip-part2-00
None
| Document | Document type |
Expired Internet-Draft
(calsch WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Authors |
Frank Dawson
,
Ross Hopson
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |