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-imip-00.txt
< prev
next >
Wrap
Text File
|
1997-05-02
|
188KB
|
5,581 lines
Network Working Group Frank Dawson, Lotus
Internet Draft
<draft-ietf-calsch-imip-00.txt> May 1, 1997
Expires November 1997
iCalendar Message-based Interoperability Protocol (iMIP)
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 document defines an iCalendar Message-based Interoperability
Protocol (iMIP), intended to be used to convey calendaring and
scheduling semantics between different applications. This document is
also being offered as a specification for demonstrating industry-
wide, calendaring and scheduling interoperability.
The message-based protocol defined by this document is useful not
only in traditional electronic messaging (e-mail) transports, but
also is applicable for conveying calendaring and scheduling
information across any reliable transport; including memory-based
clipboards, drag/drop protocols, wireless pagers, and the Infra-red
Data Association (IrDA) object transfer protocol. 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).
This design document is heavily based on the prior work of the Versit
Consortium's Personal Data Interchange (PDI) project team; including
the vCard v2.1 and the vCalendar v1.0 specifications. More
information about the PDI project and these documents can be found on
the Internet Mail Consortium (IMC) website at http://www.imc.org/pdi.
Dawson 1 Expires November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
In addition, this design document makes use of the work within the
Internet Engineering Task Force (IETF) Calendaring and Scheduling
(CALSCH) working group. More information about the IETF CALSCH
working group activities can be found on the IMC website at
http://www.imc.org, the IETF website at
http://www.ietf.org/html.charters/calsch-charter.html. Refer to the
references within this document for further information on how to
access these various documents.
Distribution of this document is unlimited. Comments and suggestions
for improvement should be sent as MIME email to the author.
Table of Contents
1. Intended Use........................................................3
1.1 Desktop Interoperablity ..........................................4
2. Message Based Architecture..........................................5
3. iCalendar Support...................................................6
3.1 Differences From iCalendar .......................................6
3.1.1 Character Set .................................................7
3.1.2 ATTENDEE Property .............................................7
3.1.3 DESCRIPTION Property ..........................................7
3.1.4 SUMMARY Property ..............................................8
3.1.5 PRODID Property ...............................................8
3.1.6 VERSION Property ..............................................8
3.1.7 PROFILE Property ..............................................8
3.1.8 PROFILE-VERSION Property ......................................9
3.1.9 UID Property ..................................................9
3.1.10 RELATED-TO Property ..........................................9
3.1.11 URL Property .................................................9
3.1.12 REQUEST-STATUS Property .....................................10
3.1.12.1 COMMENT Property ........................................13
3.2 Free and Busy Time ..............................................13
3.2.1 Freebusy Calendar Component ..................................14
3.2.2 FREEBUSY Property ............................................14
4. Supported Capability...............................................14
4.1 Request and reply to an event ...................................15
4.2 Cancel an event .................................................16
4.3 Request and reply to a to-do ....................................17
4.4 Negotiate an alternate event definition .........................18
4.5 Delegate an event to another individual .........................20
4.6 Request and reply for busy time .................................21
5. Message Profile Specifications.....................................22
6. Message Types......................................................24
6.1 EVENT-REQUEST ...................................................24
6.2 EVENT-REPLY .....................................................27
6.3 EVENT-CANCEL ....................................................32
6.4 EVENT-REPLACE ...................................................35
6.5 EVENT-COUNTER ...................................................38
6.6 EVENT-DECLINECOUNTER ............................................41
6.7 EVENT-DELEGATE ..................................................46
6.8 TODO-REQUEST ....................................................50
Dawson 2 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
6.9 TODO-REPLY ......................................................54
6.10 TODO-CANCEL ....................................................58
6.11 JOURNAL-REQUEST ................................................61
6.12 JOURNAL-REPLY ..................................................63
6.13 BUSY-REQUEST ...................................................66
6.14 BUSY-REPLY .....................................................69
7. MIME Message Format Binding........................................74
7.1 MIME Media Type .................................................74
7.2 Security ........................................................74
7.3 RFC 822 Addresses ...............................................74
7.4 Content Type ....................................................75
7.5 Content-Transfer-Encoding .......................................75
7.6 Content-Description .............................................76
7.7 To ..............................................................76
7.8 From ............................................................76
7.9 Cc and Bc .......................................................76
7.10 Reply-To .......................................................76
7.11 Subject ........................................................76
8. Alternate Plain-text Messages......................................76
8.1 EVENT-REQUEST, RSVP=YES .........................................77
8.2 EVENT-REQUEST, RSVP=NO ..........................................77
8.3 EVENT-REQUEST, EXPECT=REQUIRED ..................................78
8.4 EVENT-CANCEL ....................................................79
8.5 EVENT-REPLACE, RSVP=YES .........................................79
8.6 EVENT-DECLINECOUNTER ............................................80
8.7 EVENT-DELEGATE, RSVP=YES ........................................81
8.8 TODO-REQUEST, RSVP=YES ..........................................82
8.9 TODO-REQUEST, RSVP=NO ...........................................82
8.10 TODO-CANCEL ....................................................83
8.11 JOURNAL-REQUEST, RSVP=YES ......................................84
8.12 JOURNAL-REQUEST, RSVP=NO .......................................84
9. IrDA Binding.......................................................85
10. TCP LAN Protocol Binding..........................................85
11. SPX LAN Protocol Binding..........................................85
12. Desktop Interaction Requirements..................................85
12.1 Clipboard ......................................................85
12.2 Drag/Drop ......................................................85
12.3 File System ....................................................86
12.4 IrDa Communications ............................................86
13. Conformance.......................................................86
14. References........................................................86
15. Acknowledgements..................................................87
16. Author's Address..................................................87
17. Issues............................................................88
18. Resolutions.......................................................88
1. Intended Use
This document defines a set of message types that provide a full set
of inter-personal scheduling semantics. These capabilities include
the following:
Dawson 3 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
. Request that an event or to-do be scheduled on one or more
recipients calendars;
. Reply to an existing event or to-do request to confirm, decline,
tentative, or delegate the request;
. Allow a recipient of an event request to forward it to one or more
delegated recipients;
. Allow the originator of an event to cancels the event;
. Allow the originator of an event to replace the original event
definition, as when an event is rescheduled or the attendee
information is updated;
. Allow a recipient of an event request to send the originator a
counter-proposal;
. Allow the originator of an event request to decline a counter
proposal from an attendee;
. Request busy time data from one or more recipients;
. Reply to a busy time request with busy time data;
. Support Internet protocol access to C&S capability;
. Support LAN protocol access to C&S capability;
. Allow specification of a recurring event description with a
recurrence grammar, a sequence of events, or a combination of the
two. Recurrence grammar will allow Yearly-by-day-position,
Monthly-by-days-of-week, Monthly-by-day-position, Weekly-by-days-
of-week, Weekly-by-position, Daily-by-time;
. Support scheduling a meeting between individuals in different time
zones;
. Support for time zones;
. Support for DST rules; and
. Attachment of files to an event or to-do request.
In addition, the following real-time functions are supported:
. Request a busy time URL from an LDAP server; and
. Retrieve busy time from a busy time URL.
1.1 Desktop Interoperablity
This document was not explicitly intended to address application
interoperability at the desktop. However, in order to maximize the
Dawson 4 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
largest possible interoperability between applications, the following
recommendations are provided. Applications supporting this document
SHOULD provide support for:
. Drag/source of calendar data, rendered as an iCalendar Object,
using both clipboard and file based drag/drop protocols;
. Drop/target of an iCalendar Object using both clipboard and file
based drag/drop protocol;
. Clipboard/Copy of a calendar data rendered as an iCalendar Object;
. Clipboard/Paste of a iCalendar Object from the clipboard;
. File/Open of an iCalendar Object from the file system;
. File/SaveAs of calendar data as an iCalendar Object to the file
system;.
. Ability to invoke the product with an iCalendar Object as an
argument list item.
. Send calendar data, rendered as an iCalendar Object, over the
Win95/NT infra-red port; and
. Receive an iCalendar Object from the infra-read port.
2. Message Based Architecture
The calendaring and scheduling capability defined by this document is
based on the exchange of messages between an organizer of an event or
to-do and the attendees of the group event or to-do. For the most
part, the message protocol emulates a "request" and "reply" form of
communications.
The message format is designed to be used with a MIME electronic
messaging transport, but is equally applicable to other non-Internet
message transports.
The messages that define this inter-personal scheduling protocol
consist of an iCalendar Object defined by [ICAL].
Depending on the transport used to convey the protocol, additional
message header properties may be used to further encapsulate the
iCalendar Object. For example, within a MIME [RFC2045] transport the
[ICAL] object will be encapsulated within a [RFC 822] message entity.
Other transports may not further encapsulate the iCalendar Object.
This message-based protocol is based "request" messages that are send
from an originator to one or more recipients. A recipient of a
"request" message may "reply" to the request, in order to update
their status as an attendee and may also return transaction/request
status information. In the case of event requests, the recipient may
alternatively respond to the request with a counter proposal. The
Dawson 5 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
protocol also supports the ability for the originator of an event or
to-do request to cancel the original request. The originator of a
request may also replace the definition for the original request.
When the updated request changes the date, time or location of the
request, this effectively re-schedules the original request.
The originator of a request is by default the OWNER of the request.
Alternately, the originator may be the ORGANIZER of the request;
acting on behalf of the OWNER. The recipients of the request are by
default the ATTENDEES of the request. A recipient may delegate the
request to one of more individuals; in which case they would be a
DELEGATE of the request. The OWNER, ORGANIZER, ATTENDEE and DELEGATE
are role definitions that an attendee may be assigned by the OWNER of
the request.
The message-based protocol defined by this specification involves an
ORGANIZER/OWNER centric flow. Both the requests, cancellation,
replacement, acceptance of counter proposals can be originated only
from the ORGANIZER or OWNER of the request.
3. iCalendar Support
The messages used by this protocol are formatted according to the
IETF iCalendar specification [ICAL]. This document was selected as
the basis for the message types because it is the focus on an ongoing
effort to define an Internet calendaring and scheduling standard.
This document enhances the base [ICAL] specification with a minimum
of additional features. These include the following changes:
. iCalendar default character is UTF-8;
. Additional property parameter values for several properties;
. Extension to the URL property to allow reference to a busy time
data store;
. Constraints on some property values;
. Definition of a number of non-standard properties. The non-
standard properties where defined instead of new properties in
order to allow use of the currently available parser/generator
code base.
3.1 Differences From iCalendar
The basic capabilities defined by the [ICAL] document have utilized
to define a primarily "request" and "reply" based scheduling
protocol. In defining the protocol, some differences from the [ICAL]
specification have been introduced. The following sections describe
individual differences between the [ICAL] specification and this
design document. In addition, any constraints on the iCalendar
specification are defined.
Dawson 6 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
3.1.1 Character Set
The default character set for iCalendar Objects conforming to this
specification is UTF-8. UTF-8 is the designation for a 8-bit form of
UNICODE that preserves the encoding of US-ASCII data, but also
provides for the inclusion of non-ASCII characters from the extended
Latin alphabet or any other character block supported by [UNICODE].
This limitation will not impact existing applications that emit
iCalendar objects, but will facilitate applications that conform to
this design document to address current internationalization/national
language requirements.
3.1.2 ATTENDEE Property
The property parameters for this property have been extended to
include newly defined property parameters DELEGATED-TO, to indicate
the RFC 822 address of the individual that this attendee delegated
the request to, and DELEGATED-FROM to indicate the RFC 822 address of
the individual that this attendee received a delegated request from.
NOTE: These property parameters should be included in the current
[ICAL] document.
The DELEGATED-TO property parameter value is an (RFC 822) address
that represents the individual (e.g., "delegatee") that this request
has been deletated to.
The DELEGATED-FROM property parameter value is an (RFC 822) address
that represents the individual (e.g., "delegator") from whom this
request was delegated.
A recipient delegated as request MUST inherit the RSVP and EXPECT
values from the attendee that delegated the request to them.
The following is an example of this property with "delegatee" and
"delegator" information for an event:
ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:John Smith <jsmith@host1.com>
ATTENDEE;ROLE=DELEGATE;STATUS=TENTATIVE;DELEGATED-FROM=
iamboss@host2.com:Henry Cabot<hcabot@host2.com>
ATTENDEE;ROLE=ATTENDEE;STATUS=DELEGATED;DELEGATED-TO=
hcabot@host2.com=iamboss(The Big Cheese)@host2.com
ATTENDEE;ROLE=DELEGATE;STATUS=ACCEPTED:Jane Doe <jdoe@host1.com>
The EXPECT property parameter value of IMMEDIATE MUST not be used.
This semantic is provided by the RSVP property parameter value of
YES.
3.1.3 DESCRIPTION Property
The minimum support for the DESCRIPTION property in a recipient MUST
be for a 4095 byte value. Implementations MAY truncate longer length
values.
Dawson 7 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
3.1.4 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.1.5 PRODID Property
This property identifies the product that generated the iCalendar
object. This property MUST be included in an iCalendar object that
conforms to this design document. The value for Lotus products should
be based on an ISO 9070 formal public identifier text. The value for
Lotus products should be of the form:
prodid-value = ownerid ownerprefix textid
ownerd = "-//"
;This specifies an unregistered owner identifier
ownerprefix = compname "/" prodname
textid = "//NONSGML" space version "//EN"
;This specifies the NONSGML data entity, type of public text
;class. The "EN" text tail specifies the natural language in
;which the public text was written.
compname = 1*WORD
;This is a unique text corresponding to the company name
prodname = 1*WORD
;This is a unique text corresponding to the product family name
;e.g., "Organizer" or "ccMail"
version = <product version identifier>
;e.g., "97 GS 19970314", "R5.0 19971216", "R8 19970214"
;These examples need to be replaced with formally selected text
For example, the Lotus Organizer97 GS support for the iCalendar
object might be specified by the following:
-//Lotus/Organizer//NONSGML Organizer97 GS//EN
3.1.6 VERSION Property
The VERSION property identifies the particular version of the
iCalendar specification that the iCalendar object conforms to. The
[ICAL] specification uses the "2.0" text for its unique identifier.
This same value MUST be specified in iCalendar Objects conforming to
this document.
3.1.7 PROFILE Property
This property MUST be specified on any iCalendar Objects that conform
to this document. The property defines the usage profile or method
Dawson 8 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
being conveyed by the iCalendar object. The value of this property
MUST be one of the values defined by this document.
When included in a MIME message entity, the value of this property
MUST be the same as the Content-Type profile parameter value.
3.1.8 PROFILE-VERSION Property
This property specifies the version of the profile that the messages
in the iCalendar object correspond with. For iCalendar messages that
conform to this design document, the value MUST be "0.9".
3.1.9 UID Property
Each event and to-do calendar entity MUST be identified with a
persistent, globally unique identifier. This identifier is created by
the calendar system that generates an iCalendar Object. The
identifier is represented as a text value. It is found in the UID
property within the iCalendar calendar component descriptions for the
event or to-do. Any message type that refers to the original EVENT-
REQUEST or TODO-REQUEST MUST use this same identifier as the value of
their UID property. For example, if individual "B" sends an EVENT-
COUNTER message to individual "A" (i.e., the OWNER and/or ORIGINATOR
of the EVENT-REQUEST), the EVENT-COUNTER message must include the UID
value from the original event request message. This is the method for
correlating scheduling messages with the referenced event or to-do.
The UID value for an instance of a recurrence rule is formatted such
that it consists of the UID of the initial event or to-do, followed
by the "/" SLASH character, followed by the date and time that the
recurrence instance starts. This agreement will allow recurrence
instances to uniquely identified.
3.1.10 RELATED-TO Property
The UID value is also used by the RELATED-TO property in order to
represent relationships among events and to-dos. For example, the
parent relationship of an event to a series of action items (i.e.,
to-dos) may be show by the RELATED-TO property within the to-do
descriptions. The value of the RELATED-TO property would be the UID
of the parent event. Linkages between a sequence of events can also
be show by including RELATED-TO properties in each item in the event-
sequence, referencing back to the parent event. Backward traversal of
the sequence is completed when a referenced event or to-do is found
without a RELATED-TO property.
3.1.11 URL Property
The property definition of the URL property has been extended to
include the property parameter TYPE. The value BUSY may be specified
to indicate that the URL specifies the location of busy time data
associated with the originator of the message. For example, an
originator for an EVENT-REQUEST message may specify this property
parameter/value pair to specify the URL where the ATTENDEE might
Dawson 9 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
search for busy time in order to construct a counter proposal. By
using the busy time data specified by this URL, a recipient might
determine an alternate free time for a counter proposal or a
rescheduling of an event. Multiple occurrences of the URL property
may indicate different resource locations. Busy time pointed to by a
busy time URL must be an iCalendar Object.
Editor's Note: Should there be additional constraints on the
format of a busy file URL?
3.1.12 REQUEST-STATUS Property
This newly defined property is identified by the property name
REQUEST-STATUS. This property is used to return status information
related to the processing of an associated iCalendar Object. The
property MUST only be used in an EVENT-REPLY, EVENT-DECLINECOUNTER,
TODO-REPLY, JOURNAL-REPLY or BUSY-REPLY message. The data type for
this property is TEXT. The value consists of a short return status, a
longer return status description, and optionally the offending data.
The components of the value are separated by the SEMICOLON character
(ASCII decimal 59).
NOTE: These property parameters should be included in the base [ICAL]
document.
The property is defined by the following notation:
rstatus = "REQUEST-STATUS" ":" statcode ";"
statdesc [";" extdata]
statcode = 3*DIGIT
;Numeric return status code
statdesc = *WORD
;Textual status description
extdata = *WORD
;Textual exception data. For example, the offending property
;name and value or complete property line.
The following are some examples of this property:
REQUEST-STATUS:0;Success
REQUEST-STATUS:101;Invalid property value;DTSTART\:96-Apr-01
;Note escapement of the colon character in property value.
REQUEST-STATUS:201;Invalid Property Value;RRULE
REQUEST-STATUS:301;Event conflict. Date/time is busy.
REQUEST-STATUS:403;Invalid calendar user;ATTENDEE:
jsmith@host.com
Dawson 10 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
The following are valid values for the short return status and the
longer return status description:
Short Return Longer Return Status Description
Status Value
0 Success
1XX Syntax value errors
2XX Semantic and value errors
3XX Scheduling errors
4XX Security related errors
The following is a list of possible exception values:
Short Return Longer Return Status Offending Data
Status Description
0 Success. None.
10 Success, but fallback
taken on one or more may be specified. Property name and value
property values.
11 Success, invalid Property name may be
property ignored. specified.
12 Success, invalid Property parameter name
property parameter and value may be
ignored. specified.
13 Success, unknown non- Non-standard property
standard property name may be specified.
ignored.
14 Success, unknown non- Property and non-
standard property value standard value may be
ignored. specified.
15 Success, invalid Calendar component
calendar component sentinel (e.g.,
ignored. "BEGIN:ALARM") may be
specified.
Dawson 11 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
16 Success, request Original and forwarded
forwarded to calendar RFC822 addresses may be
user. specified.
17 Success, repeating event RRULE or RDATE property
ignored. Scheduled as a name and value may be
single event. specified.
18 Success, truncated end DTEND property value may
date/time to date be specified.
boundary.
19 Success, repeating to-do RRULE or RDATE property
ignored. Scheduled as a name and value may be
single to-do. specified.
100 Invalid property name. Property name may be
specified.
101 Invalid property value. Property name and value
may be specified.
102 Invalid property Property parameter name
parameter. and value may be
specified.
103 Invalid property Property parameter name
parameter value. and value may be
specified.
104 Invalid calendar Calendar component
component sequence. sentinel may be
specified (e.g.,
BEGIN:TIMEZONE).
201 Invalid date or time. Date/time value(s) may
be specified.
202 Invalid rule. Rule value may be
specified.
203 Request not supported. Profile property value
may be specified.
204 Invalid calendar user. Attendee property value
may be specified.
301 Event conflict. DTSTART and DTEND
Date/time is busy. property name and values
may be specified.
302 Request not supported. PROFILE property value
Dawson 12 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
may be specified.
401 Service unavailable. ATTENDEE property value
may be specified.
402 Invalid calendar ATTENDEE property value
service. may be specified.
403 Invalid calendar user. ATTENDEE property value
may be specified.
404 No scheduling support ATTENDEE property value
for user. may be specified.
405 No authority. PROFILE and ATTENDEE
property values may be
specified.
3.1.12.1 COMMENT Property
This newly defined property is identified by the property name
COMMENT. The property is used to pass a comment text within the
calendar component. The property may use the ENCODING property
parameter to reset the default encoding to QUOTED-PRINTABLE in order
to include formatting characters within the comment text. For
example, the property can be used within an EVENT-REPLY to indicate
to the OWNER of an event request why an ATTENDEE is declining an
invitation.
NOTE: These property parameters should be included in the base [ICAL]
document.
The minimum support MUST be for a 4095 byte value. Implementations
MAY truncate longer length values.
The following is an example of this property.
COMMENT:The meeting really needs to include both ourselves
and the customer. We can't hold this meeting without them.
As a matter of fact, the venue for the meeting ought to be at
their site. - - Frank
3.2 Free and Busy Time
The [ICAL] specification provides support for representing free or
busy time data. This document only supports the request and replies
for busy-time information.
Dawson 13 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
3.2.1 Freebusy Calendar Component
This design document only addresses the transfer of busy time
information. Applications desiring free time information must infer
this 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.
3.2.2 FREEBUSY Property
An iCalendar Object conforming to document MUST restrict the use of
the BUSYTIME 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 BUSYTIME
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 before yesterday's busy time information.
And the busy time for this half hour SHOULD appear before the busy
time for earlier today.
Since events MAY span a day boundary, free busy time period MAY also
span a day boundary.
4. Supported Capability
The message types defined by this usage profile provides for the
scheduling functions that allow:
. An originator to request that an event be scheduled between
the originator and one or more recipients (EVENT-REQUEST);
. A recipient of an event request to reply to the originator of
the request (EVENT-REPLY);
Dawson 14 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
. An originator of an existing event request to send a
cancellation notice to the attendees (EVENT-CANCEL);
. An originator of an existing event request to reschedule the
event (EVENT-REPLACE);
. An originator of an existing event request to send the
attendees an updated event description and attendee statuses
(also the EVENT-REPLACE);
. A recipient of an event request to delegate the request to
another recipient (EVENT-DELEGATE);A recipient of an event
request to send a counter proposal to the originator of the
request (EVENT-COUNTER);
. An originator of an existing event request to decline a
counter proposal from a recipient (EVENT-DECLINECOUNTER);
. An originator to request an action item or to-do to be
assigned to one or more recipients (TODO-REQUEST);
. A recipient of a to-do request to reply to the originator of
the request (TODO-REPLY);
. An originator of an existing to-do request to send a
cancellation notice to the attendees (TODO-CANCEL);
. An originator to request that a journal entry be appended to
one or more recipients (JOURNAL-REQUEST);
. A recipient of a journal request to reply to the originator
of the request (JOURNAL-REPLY);
. Originator to request busy time from one or more recipients
(BUSY-REQUEST);
. A recipient of a busy time request to reply to the originator
of the request with busy time intervals (BUSY-REPLY).
The following scenarios describe how these scheduling functions are
supported by this message protocol.
4.1 Request and reply to an event
Individual "A" requests a meeting between individuals "A", "B", "C"
and "D". Individual "B" confirms attendance to the meeting.
Individual "C" declines attendance. Individual "D" tentatively
confirms their attendance. This is sometime 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.
Dawson 15 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Action Originator Recipient
Initiate a meeting "A" sends EVENT-REQUEST
request message to "B" and "C"
Accept the meeting "B" sends EVENT-REPLY
request message to "A" with
it's ATTENDEE/STATUS
property parameter set
to "ACCEPTED"
Decline the meeting "C" sends EVENT-REPLY
request message to "A" with
it's ATTENDEE/STATUS
property parameter set
to "DECLINED"
Tentatively accept the "D" sends EVENT-REPLY
meeting request message to "A" with
it's ATTENEE/STATUS
property parameter set
to "TENTATIVE"
Confirm meeting status "A" sends EVENT-REPLACE
with attendees message to "B" and "C"
with current
information for event.
SEQUENCE property is
"1".
4.2 Cancel an 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 or to-do must be
ignored.
Dawson 16 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Action Originator Recipient
Initiate a meeting "A" sends EVENT-REQUEST
request message to "B" and "C"
Decline the meeting "B" sends EVENT-REPLY
request 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 meeting "A" sends EVENT-CANCEL
message to "B" and "C"
to cancel the meeting.
SEQUENCE parameter is
"1".
The cancelation of a to-do is achieved in a manner similar to this.
4.3 Request and reply to a to-do
Individual "A" assigns a to-do to individual "B". Individual "B"
accepts the to-do. Subsequently, individual "B" replies to individual
"A" that the to-do is completed. The following table illustrates the
sequence of messages that would be exchanged between these
individuals.
The request and reply of a journal entry operates similar to this
also.
Dawson 17 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Action Originator Recipient
Assign a to-do "A" sends TODO-REQUEST
message to "B".
Accept the to-do "B" sends TODO-REPLY
message to "A" with
it's ATTENDEE/STATUS
property parameter set
to "ACCEPTED"
Reply when to-do is "B" sends TODO-REPLY
completed message to "A" with
it's ATTENDEE/STATUS
property parameter set
to "COMPLETED".
RESPONSE-SEQUENCE
property is "1"
A similar set of messages could have been exchanged to assign a to-do
to a group of individuals.
4.4 Negotiate an alternate event definition
Individual "A" requests a meeting between individuals "A", "B" and
"C". Individual "B" confirms attendance to the meeting. Individual
"C" sends individual "A" a counter proposal for the meeting.
Individual "A" accepts the counter proposal. Individual "C" confirms
attendance to the meeting. Individual "B" accepts the modified
meeting request. Individual "A" distributes the revised meeting
details and attendees status. The following table illustrates the
sequence of messages that would be exchanged between these
individuals.
Action Originator Recipient
Initiate a meeting "A" sends EVENT-REQUEST
request message to "B" and "C"
Accept the meeting "B" sends EVENT-REPLY
request message to "A" with
Dawson 18 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
it's ATTENDEE/STATUS
property parameter set
to "ACCEPTED"
Counter proposal for "C" sends EVENT-COUNTER
the meeting request message to "A"
signaling a request to
revise some detail
about the request
Accept the counter "A" sends EVENT-REPLACE
proposal message to "B" and "C".
SEQUENCE parameter is
"1". The STATUS
parameter on all
ATTENDEE properties
MUST be reset to "NEEDS
ACTION".
Confirm revised meeting "C" sends EVENT-REPLY
request message to "A" with
it's ATTENDEE/STATUS
property parameter set
to "ACCEPTED".
RESPONSE-SEQUENCE
parameter is "0" and
SEQUENCE parameter is
"1".
"B" sends EVENT-REPLY
message to "A" with
it's ATTENDEE/STATUS
property parameter set
to "ACCEPTED".
RESPONSE-SEQUENCE
parameter is "0" and
SEQUENCE parameter is
"1".
Confirm meeting details "A" sends a second
and status to attendees EVENT-REPLACE message
to "B" and "C" with
current information for
event. SEQUENCE
property is "2".
Dawson 19 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Individual "A" could have declined the counter proposal for the
meeting request with the EVENT-DECLINE-COUNTER message. Individual
"B" could have declined attendance at the meeting with the EVENT-
REPLY message or delegated the original meeting request with a
combination of the EVENT-REPLY to the originator and the EVENT-
DELEGATE to the delegated individual (e.g., Individual "D", sometimes
called "delegatee".).
4.5 Delegate an event to another individual
Individual "A" requests a meeting between individuals "A" and "B".
Individual "B" delegates attendance to the meeting to individual "C".
Individual "C" confirms attendance to the meeting. Individual "A"
distributes the revised meeting details and attendee status. The
following table illustrates the sequence of messages that would be
exchanged between these individuals.
Action Originator Recipient
Initiate a meeting "A" sends EVENT-REQUEST
request message to "B" and "C"
Delegate the meeting "B" sends EVENT-REPLY
request message to "A" with
it's ATTENDEE/STATUS
property parameter set
to "DELEGATED" and an
ATTENDEE property has
been added to the reply
for "C" with a
DELEGATED-FROM property
parmater set to address
of "B". DELEGATED-TO
property parameter for
B set to address of
"C".
"B" sends EVENT-
DELEGATE message to "C"
with the original
meeting request
information. The
ATTENDEE/STATUS
property parameter for
"B" has been set to
"DELEGATED" and the
ATTENDEE/DELEGATED-TO
parameter has been set
Dawson 20 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
to the address of "C".
An ATTENDEE property
has been added for "C"
and the
ATTENDEE/DELEGATED-FROM
parameter has been set
to the address of "B".
Confirm meeting "C" sends EVENT-REPLY
attendance message to "A" and "B"
with it's
ATTENDEE/STATUS
property parameter set
to "ACCEPTED"
Redistribute meeting "A" sends EVENT-REPLACE
details and status to message to "B" and "C"
attendees with current
information for event.
SEQUENCE property is
"1"
Individual "C" could have declined the delegated proposal for the
meeting request with the EVENT-REPLY message being sent to both "A"
and "B".
4.6 Request and reply for busy time
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.
Action Originator Recipient
Initiate a busy time "A" sends BUSY-REQUEST
request message to "B", "C" and
"D"
Dawson 21 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Reply to the busy time "B" and "C" sends BUSY-
request with busy time REPLY message to "A"
data with their busy time
data.
(Assuming transport "D" sends an exception
supports exchange of message (i.e., 302) to
exception messages) "A"
Reply that busy time
requests is an
unsupported capability.
5. Message Profile Specifications
This section specifies the individual message formats defined by this
design document. It is heavily based on the [ICAL] and [ID-CSP]
documents. The message formats also borrow from the on-going
discussions within the IETF Calendaring and Scheduling Working Group.
Each individual message format is identified by the value of the
PROFILE calendar property. If a [ICAL] defined property is not
specified in an individual message format, then it is not allowed in
the message type.
Each message type provides support for a specific scheduling
function. Taken as a whole, these message types provide support for a
robust level of calendaring and scheduling functionality. These
message types are summarized in the following table. Only the
following message types are supported by this usage profile.
Profile Parameter Description
Value
EVENT-REQUEST Make a request for an
event
EVENT-REPLY Reply to an event
request
EVENT-CANCEL Cancel an existing
event request
Dawson 22 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
EVENT-REPLACE Replace the current
event request with a
complete set of
properties
EVENT-DELEGATE Delegate an existing
event request
EVENT-COUNTER Make a counter proposal
to the event request
EVENT-DECLINECOUNTER Decline the counter
proposal to the event
request
TODO-REQUEST Assign a to-do
TODO-REPLY Reply to a to-do
assignment
TODO-CANCEL Cancel an existing to-
do request.
JOURNAL-REQUEST Request that a a
journal entry gets
appended to a calendar
date.
JOURNAL-REPLY Reply to a journal
request.
BUSY-REQUEST Request free or busy
time data
BUSY-REPLY Reply to a free/busy
time request
Dawson 23 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
6. Message Types
This design document is meant to serve as the basis for implementing
a message-based scheduling function within calendaring and scheduling
products. In order to meet this goal, a common set of message-based
scheduling semantics or functionality needs to be defined. The
messages defined in this section provide such a set of semantics.
The message definitions do not include a binding to the MIME email
transport. This information is provided in a subsequent section of
this document.
In the following tables, the properties are classified as either
ALWAYS (i.e., "A"), EXCLUDED (i.e., "X") or SOMETIMES (i.e., "S").
Additionally, the values for the properties may be constrained; as
indicated in the descriptive text for that property. Properties
classified as ALWAYS MUST appear within instances of the message
type. Properties classified as EXCLUDED MUST NOT appear within
instances of the message type. Properties classified as SOMETIMES MAY
appear within instances of the message type.
Implementations conforming to this document MUST be able to parse,
and store for possible forwarding, all properties classified as
ALWAYS and SOMETIMES..
6.1 EVENT-REQUEST
This message type is used to request a new event with a one or more
people. The message is sent from an originator (i.e., ROLE=OWNER or
ORGANIZER) of an event request to one or more intended recipients
(i.e., ROLE=ATTENDEE). The originator MUST be either the OWNER or
ORGANIZER of the event.
This message MUST not be used to reschedule an event. The EVENT-
REPLACE or a sequence of the EVENT-CANCEL followed by the EVENT-
REQUEST profile types MUST be used by the originator to change or
reschedule this event.
If an Alarm is specified in an EVENT-REQUEST, it is only specified as
a suggestion. A recipient may ignore the Alarm component entirely. A
recipient is not obligated to use any information defined in the
Alarm component. However, the recipient should forward all alarm
information in a delegated request.
EVENT-REQUEST
Calendar Properties
GEO S
PRODID A
Dawson 24 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
VERSION A, Value must be "2.0".
PROFILE A,"EVENT-REQUEST"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
COMMENT X
CREATED S
DAYLIGHT S
DTSTART A
DTEND S
RDATE S, Either RDATE or RRULE may
be specified, but not both.
RRULE S, Either RDATE or RRULE may
be specified, but not both.
TZNAME S
TZOFFSET A
TZTRANS S
UID S
Event Component Properties
ATTACH S, "VALUE=URL" only.
ATTENDEE A, Value is an RFC822 mailbox
address for C&S capability.
STATUS parameter is either
absent or has value "NEEDS
ACTION".
CATEGORIES S
CLASS S
CREATED S
COMPLETED X
DESCRIPTION A, Value may be NULL text.
Dawson 25 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
DUE X
DURATION X
DTEND A, Must be a date/time after
DTSTART. May span date
boundary.
DTSTART A
EXDATE S, See issues list.
EXRULE S, See issues list.
LAST-MODIFIED S
LOCATION S
PRIORITY X
RELATED-TO S
REQUEST-REPLY X
RDATE S, See issues list.
RRULE S, See issues list.
RESOURCES S
RESPONSE- X
SEQUENCE
SEQUENCE A, If not zero
STATUS S, Value only one of TENTATIVE
| ACCEPTED. This property is
used by the originator to
indicate the consensus for the
meeting, not a status on any
of the attendees.
SUMMARY S, May be NULL text.
TRANSP X
URL S
UID A, Must be maintained by the
recipients.
To-do Component Properties
Dawson 26 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 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 S
CATEGORIES A, If an alarm is specified
CREATED S
DESCRIPTION S
DTSTART A, If an alarm is specified
DURATION A, If an alarm is specified
LAST-MODIFIED S
RELATED-TO S
REPEAT A, If an alarm is specified
SUMMARY S
URL S
Freebusy Component Properties
Freebusy component is excluded
from this message type.
Non-standard Properties
X-token S, but recipient may choose to
ignore those non-standard
properties, specified as
optional.
6.2 EVENT-REPLY
The message is used to RSVP to an existing event request. The message
is sent from a recipient of an event request back to the event
ORGANIZER. If an ORGANIZER is not specified on the request, then the
message is sent to the OWNER. The message is only used to change the
Dawson 27 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
attendee's status from NEEDS ACTION, the default, to either ACCEPTED,
DECLINED, TENTATIVE, or DELEGATED. The message may also be used by an
attendee to later change their status back to some other value.
Recipients may end up sending numerous EVENT-REPLY messages to change
their attendance status from one value to another. Individual reply
messages will have a RESPONSE-SEQUENCE property with a value that is
incremented for each reply sequence. The first reply has a RESPONSE-
SEQUENCE value of "0"; the second a value of "1", etc.
This message type is not used to make a counter proposal to an event
request. This would be accomplished by sending an EVENT-COUNTER
message to the ORGANIZER of the original event. If an ORGANIZER is
not specified on the request, then the message is sent to the OWNER.
The UID of the original event request is used as the primary key for
the event that is being replied to.
An EVENT-REPLY to a recurring event can confirm, tentatively confirm
or decline the whole event request or individual instances of a
recurrence sequence.
EVENT-REPLY
Calendar Properties
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"EVENT-REPLY"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
Timezone component is excluded
from this message type.
Event Component Properties
ATTACH X
ATTENDEE A, Value is an RFC822 mailbox
address for C&S capability.
Must be the address of the
recipient replying.
CATEGORIES X
Dawson 28 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
CLASS X
COMMENT Text value. Provides a comment
from the recipient to the
originator about the reply.
For example, "I can't travel
this far for a meeting."
CREATED X
COMPLETED X
DESCRIPTION X
DUE X
DURATION X
DTEND X
DTSTART X
EXDATE S, See issues list. Specifies
the dates that are exceptions
to the status update.
EXRULE S, See issues list. Specifies
the rule that defines the
exceptions to the status
update.
LAST-MODIFIED X
LOCATION X
PRIORITY X
RELATED-TO X
REQUEST- Any of the values defined in
STATUS the table below.
RDATE X
RRULE X
RESOURCES X
RESPONSE- A, If not zero.
SEQUENCE
SEQUENCE A, If not zero
Dawson 29 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
STATUS X Status for attendee must be
specified in STATUS parameter
of ATTENDEE property.
SUMMARY X
TRANSP X
URL X
UID A, 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
X-token S, But recipient may choose to
ignore those non-standard
properties, specified as
optional.
The REQUEST-STATUS property may include the following values:
Short Return Longer Return Status Offending Data
Status Description
0 Success. None.
Dawson 30 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
10 Success, but fallback Property name and value
taken on one or more may be specified.
property values.
11 Success, invalid Property name may be
property ignored. specified.
12 Success, invalid Property parameter name
property parameter and value may be
ignored. specified.
13 Success, unknown non- Non-standard property
standard property name may be specified.
ignored.
14 Success, unknown non-
standard property value standard value may be Property and non-
ignored. specified.
15 Success, invalid Calendar component
calendar component sentinel (e.g.,
ignored. "BEGIN:ALARM") may be
specified.
16 Success, request Original and forwarded
forwarded to calendar RFC822 addresses may be
user. specified.
17 Success, repeating event RRULE or RDATE property
ignored. Scheduled as a name and value may be
single event. specified.
18 Success, truncated end DTEND property value may
date/time to date be specified.
boundary.
100 Invalid property name. Property name may be
specified.
101 Invalid property value. Property name and value
may be specified.
102 Invalid property Property parameter name
parameter. and value may be
specified.
103 Invalid property Property parameter name
parameter value. and value may be
specified.
104 Invalid calendar Calendar component
component sequence. sentinel may be
Dawson 31 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
specified (e.g.,
BEGIN:TIMEZONE).
201 Invalid date or time. Date/time value(s) may
be specified.
202 Invalid rule. Rule value may be
specified.
203 Request not supported. Profile property value
may be specified.
204 Invalid calendar user. Attendee property value
may be specified.
301 Event conflict. DTSTART and DTEND
Date/time is busy. property name and values
may be specified.
302 Request not supported. PROFILE property value
may be specified.
401 Service unavailable. ATTENDEE property value
may be specified.
402 Invalid calendar ATTENDEE property value
service. may be specified.
403 Invalid calendar user. ATTENDEE property value
may be specified.
404 No scheduling support ATTENDEE property value
for user. may be specified.
405 No authority. PROFILE and ATTENDEE
property values may be
specified.
6.3 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 original event
request. The OWNER and ORGANIZER are ROLE parameter values for the
ATTENDEE property.
EVENT-CANCEL
Dawson 32 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Calendar Properties
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"EVENT-CANCEL"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
Timezone component is excluded
from this message type.
Event Component Properties
ATTACH X
ATTENDEE X
CATEGORIES X
CLASS X
CREATED X
COMMENT S, Text value. Provides a
comment from the originator to
the attendees concerning the
cancellation notice.
COMPLETED X
DESCRIPTION X
DUE X
DURATION X
DTEND X
DTSTART X
EXDATE X
EXRULE X
LAST-MODIFIED X
Dawson 33 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
LOCATION X
PRIORITY X
RELATED-TO X
REQUEST- X
STATUS
RDATE X
RRULE X
RESOURCES X
RESPONSE- X
SEQUENCE
SEQUENCE A if not zero
STATUS X
SUMMARY X
TRANSP X
URL S
UID A, 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
Alarm component is excluded
from this message type.
Freebusy Properties
Freebusy component is excluded
from this message type.
Dawson 34 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Non-standard Properties
X-token S, But recipient may choose to
ignore those non-standard
properties, specified as
optional.
6.4 EVENT-REPLACE
This message type is used reschedule an existing event or to provide
attendees with an up-to-date description of the event. The message is
sent from an originator (i.e., ROLE=OWNER or ORGANIZER) of an event
request to one or more intended recipients. The OWNER and ORGANIZER
are ROLE parameter values for the ATTENDEE property. The originator
MUST be either the OWNER or ORGANIZER of the event.
EVENT-REPLACE
Calendar Properties
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"EVENT-REPLACE"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
CREATED S
DAYLIGHT S
DTSTART A
DTEND S
RDATE S, Either RDATE or RRULE may
be specified, but not both.
RRULE S, Either RDATE or RRULE may
be specified, but not both.
Dawson 35 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
TZNAME S
TZOFFSET A
TZTRANS S
UID S
Event Component Properties
ATTACH S, URL only.
ATTENDEE A, Value is an RFC822 mailbox
address for C&S capability. If
used to reschedule an event,
then the STATUS parameter must
either be absent or has a
value of "NEEDS ACTION".
CATEGORIES S
CLASS S
COMMENT X
CREATED S
COMPLETED X
DESCRIPTION A, Value may be NULL text.
DUE X
DURATION X
DTEND A, 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.
DTSTART A, 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.
EXDATE S, See issues list.
EXRULE S, See issues list.
LAST-MODIFIED S
Dawson 36 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
LOCATION S
PRIORITY X
RELATED-TO O
REQUEST- X
STATUS
RDATE S, See issues list.
RRULE S, See issues list.
RESOURCES S
RESPONSE- X
SEQUENCE
SEQUENCE A if not zero
STATUS S, Value only one of TENTATIVE
| ACCEPTED. This property is
used by the originator to
indicate the consensus for the
meeting.
SUMMARY S, May be NULL text.
TRANSP X
URL S
UID A, 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 S
CATEGORIES A, If an alarm is specified
CREATED S
Dawson 37 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
DESCRIPTION S
DTSTART A, If an alarm is specified
DURATION A, If an alarm is specified
LAST-MODIFIED S
RELATED-TO S
REPEAT A, If an alarm is specified
SUMMARY S
URL S
Freebusy Component Properties
Freebusy component is excluded
from this message type.
Non-standard Properties
X-token S, but recipient may choose to
ignore those non-standard
properties, specified as
optional.
6.5 EVENT-COUNTER
This message type is used by a recipient of an event request to issue
a counter-proposal to the event. The message is sent from a recipient
of an existing event request to the OWNER and/or ORGANIZER of the
original event request. The OWNER and ORGANIZER are ROLE parameter
values for the ATTENDEE property.
Alternative counter proposals are not supported. That is, multiple
VEVENT calendar components similar to that allowed in the EVENT-REPLY
are not allowed in this message type.
The EVENT-COUNTER message must include a complete description of the
event.
EVENT-COUNTER
Calendar Properties
Dawson 38 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"EVENT-COUNTER"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
CREATED S
DAYLIGHT S
DTSTART A
DTEND S
RDATE S, Either RDATE or RRULE may
be specified, but not both.
RRULE S, Either RDATE or RRULE may
be specified, but not both.
TZNAME S
TZOFFSET A
TZTRANS S
UID S
Event Component Properties
ATTACH S, VALUE=URL only.
ATTENDEE A, 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 S
CLASS S
COMMENT A, Text value. Provides a
comment from the recipient to
Dawson 39 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
the originator about the
counter proposal. For example,
"How about my place instead of
yours".
CREATED X
COMPLETED X
DESCRIPTION A, Value may be NULL text.
DUE X
DURATION X
DTEND A, 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.
DTSTART S, 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.
EXDATE S, See issues list.
EXRULE S, See issues list.
LAST-MODIFIED X
LOCATION S
RNUM X
PRIORITY X
RELATED-TO S
REQUEST- X
STATUS
RDATE S, See issues list.
RRULE S, See issues list.
RESOURCES S
RESPONSE- A, If not zero
SEQUENCE
Dawson 40 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
SEQUENCE A, If not zero
STATUS X
SUMMARY S, May be NULL text.
TRANSP X
URL S
UID A, 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.
Freebusy Properties
Freebusy component is excluded
from this message type.
Non-standard Properties
X-token S, But recipient may choose to
ignore those non-standard
properties, specified as
optional.
6.6 EVENT-DECLINECOUNTER
This message type is used by the originator of an event request to
decline a counter proposal. The message is sent from the OWNER and/or
ORGANIZER of the original event request to the originator of the
EVENT-COUNTER message. This originator of the counter proposal
message should be one of the ATTENDEE in the original event request.
Dawson 41 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Acceptance of a counter proposal message is accomplished by the OWNER
and/or ORGANIZER of the original event request sending out an EVENT-
REPLACE message with the updated event description.
EVENT-DECLINECOUNTER
Calendar Properties
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"EVENT-DECLINECOUNTER"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Properties
Timezone component is excluded
from this message type.
Event Component Properties
ATTACH X
ATTENDEE S, 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 X
CLASS X
COMMENT S, 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 X
COMPLETED X
Dawson 42 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
DESCRIPTION X
DUE X
DURATION X
DTEND X
DTSTART X
EXDATE X
EXRULE X
LAST-MODIFIED X
LOCATION S
PRIORITY X
RELATED-TO S
REQUEST- S, One of the values from the
STATUS table below.
RDATE X
RRULE X
RESOURCES X
RESPONSE- A, Must be the same as that
SEQUENCE specified in the EVENT-
COUNTER.
SEQUENCE A, Must be the same as that
specified in the EVENT-
COUNTER.
STATUS X
SUMMARY X
TRANSP X
URL S
UID A, Must be the value of the
UID of the original EVENT-
REQUEST referenced in the
counter proposal.
Dawson 43 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
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 S, but recipient may choose to
ignore those non-standard
properties, specified as
optional.
The REQUEST-STATUS property may include the following values:
Short Return Longer Return Status Offending Data
Status Description
0 Success. None.
10 Success, but fallback Property name and value
taken on one or more may be specified.
property values.
11 Success, invalid Property name may be
property ignored. specified.
12 Success, invalid Property parameter name
property parameter and value may be
ignored. specified.
13 Success, unknown non- Non-standard property
standard property name may be specified.
Dawson 44 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
ignored.
14 Success, unknown non- Property and non-
standard property value standard value may be
ignored. specified.
15 Success, invalid
calendar component sentinel (e.g., Calendar component
ignored. "BEGIN:ALARM") may be
specified.
16 Success, request
forwarded to calendar RFC822 addresses may be Original and forwarded
user. specified.
17 Success, repeating event RRULE or RDATE property
ignored. Scheduled as a name and value may be
single event. specified.
18 Success, truncated end DTEND property value may
date/time to date be specified.
boundary.
100 Invalid property name. Property name may be
specified.
101 Invalid property value. Property name and value
may be specified.
102 Invalid property Property parameter name
parameter. and value may be
specified.
103 Invalid property Property parameter name
parameter value. and value may be
specified.
104 Invalid calendar Calendar component
component sequence. sentinel may be
specified (e.g.,
BEGIN:TIMEZONE).
201 Invalid date or time. Date/time value(s) may
be specified.
202 Invalid rule. Rule value may be
specified.
203 Request not supported. Profile property value
may be specified.
204 Invalid calendar user. Attendee property value
Dawson 45 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
may be specified.
301 Event conflict. DTSTART and DTEND
Date/time is busy. property name and values
may be specified.
302 Request not supported. PROFILE property value
may be specified.
401 Service unavailable. ATTENDEE property value
may be specified.
402 Invalid calendar ATTENDEE property value
service. may be specified.
403 Invalid calendar user. ATTENDEE property value
may be specified.
404 No scheduling support ATTENDEE property value
for user. may be specified.
405 No authority. PROFILE and ATTENDEE
property values may be
specified.
6.7 EVENT-DELEGATE
This message type is used to delegate an event request to an 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 recipient delegating the
request to the originator of the event request; indicating that the
original request is being delegated.
The EVENT-DELEGATE 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.
Dawson 46 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
EVENT-DELEGATE
Calendar Properties
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"EVENT-DELEGATE"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
CREATED S
DAYLIGHT S
DTSTART A
DTEND S
RDATE S, Either RDATE or RRULE may
be specified, but not both.
RRULE S, Either RDATE or RRULE may
be specified, but not both.
TZNAME S
TZOFFSET A
TZTRANS S
UID S
Event Component Properties
ATTACH S, VALUE=URL only.
ATTENDEE A, Value is an RFC822 mailbox
address for C&S capability. A
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
Dawson 47 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
same RSVP and EXPECT property
parameter values as the
recipient delegating the
request. The STATUS parameter
for this individual is either
absent or has a value of
"NEEDS ACTION". The ATTENDEE
property associated with the
recipient delegating the
request should include the
DELEGATED-TO property
parameter.
CATEGORIES S
CLASS S
CREATED S
COMMENT S, Text value. Provides a
comment from the originator of
the delegate message to the
delegated individual
concerning the delegated
event.
COMPLETED X
DESCRIPTION A, Value may be NULL text.
DUE X
DURATION X
DTEND A, 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.
DTSTART A, 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.
EXDATE S, See issues list.
EXRULE S, See issues list.
LAST-MODIFIED S
Dawson 48 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
LOCATION S
PRIORITY X
RELATED-TO S
REQUEST- X
STATUS
RDATE S, See issues list.
RRULE S, See issues list.
RESOURCES S
RESPONSE- X, This message not to be used
SEQUENCE for "rescheduling" an event.
SEQUENCE A if not zero
STATUS S, Value only one of TENTATIVE
| ACCEPTED. This property is
used to convey the consensus
for the meeting.
SUMMARY S, May be Null text.
TRANSP X
URL S
UID A, 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 S
CATEGORIES A, If an alarm is specified
CREATED S
Dawson 49 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
DESCRIPTION S
DTSTART A, If an alarm is specified
DURATION A, If an alarm is specified
LAST-MODIFIED S
RELATED-TO S
REPEAT A, If an alarm is specified
SUMMARY S
URL S
Freebusy Component Properties
Freebusy component is excluded
from this message type.
Non-standard Properties
X-token S, but recipient may choose to
ignore those non-standard
properties, specified as
optional.
6.8 TODO-REQUEST
This message type is used to send an assignment of a to-do or action
item to one or more recipients. The message is sent from an
originator (i.e., ROLE=OWNER or ORGANIZER) of a to-do request to one
or more intended recipients (ROLE=ATTENDEE). The OWNER and OGANIZER
are ROLE parameter values for the ATTENDEE property.
A to-do may be defined as a recurring action item.
This usage profile does not provide support the capability to
redefine a to-do, other than by canceling and assigning a newly
defined to-do.
TODO-REQUEST
Calendar Properties
GEO S
Dawson 50 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"TODO-REQUEST"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
CREATED S
DAYLIGHT S
DTSTART A
DTEND S
RDATE S, Either RDATE or RRULE may
be specified, but not both.
RRULE S, Either RDATE or RRULE may
be specified, but not both.
TZNAME S
TZOFFSET A
TZTRANS S
UID S
Event Component Properties
Event component is excluded
from this message type.
To-do Component Properties
ATTACH S, VALUE=URL only.
ATTENDEE A, Value is an RFC822 mailbox
address for C&S capability.
STATUS parameter is either
absent or has a value "NEED
ACTION".
CATEGORIES S
CLASS S
Dawson 51 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
COMMENT S
CREATED S
COMPLETED X
DESCRIPTION A, Value may be NULL text.
DUE A, Value is of the ISO 8601
complete representation, basic
format of a UTC based date and
time. This is the date and
time that the to-do is to be
completed; unless specifying a
loosely coupled date and time.
DURATION X
DTEND X
DTSTART A, Value is of the ISO 8601
complete representation, basic
format of a UTC based date and
time. This is the date that
the to-do is to first appear
on the calendar; unless
specifying a loosely coupled
date and time.
EXDATE S, See issues list.
EXRULE S, See issues list.
LAST-MODIFIED S
LOCATION X
PRIORITY A, Value must be a numeric
character representing an
integer. "0" indicates not
set. "1", "2", "3" indicate
high, medium, and low
priority, respectively.
RELATED-TO S
REQUEST- X
STATUS
RDATE S, See issues list.
RRULE S, See issues list.
Dawson 52 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
RESOURCES S
RESPONSE- X, This message is not used
SEQUENCE for "redefining" a to-do.
SEQUENCE A if not zero
STATUS X
SUMMARY S, May be Null text.
TRANSP X
URL S
UID A, Must be maintained by the
recipient.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Component Properties
ATTACH S
CATEGORIES A, If an alarm is specified
CREATED S
DESCRIPTION S
DTSTART A, If an alarm is specified
DURATION A, If an alarm is specified
LAST-MODIFIED S
RELATED-TO S
REPEAT A, If an alarm is specified
SUMMARY S
URL S
Freebusy Component Properties
Freebusy component is excluded
from this message type.
Dawson 53 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Non-standard Properties
X-token S, but recipient may choose to
ignore those non-standard
properties, specified as
optional.
6.9 TODO-REPLY
This message type is used to reply to a to-do assignment in order to
update the status and possibly the completion date of the to-do. The
message is sent from a recipient of a to-do request back to the to-do
ORGANIZER. If an ORGANIZER is not specified on the request, then the
message is sent to the OWNER.
This profile is ONLY USED to reply to an to-do request; in order to
ACCEPT or DECLINE a to-do. It is also be used by the recipient of a
TODO-REQUEST in order to confirm completion of the to-do (i.e.,
ATTENDEE;STATUS=COMPLETED:.., COMPLETED=date and time of completion).
TODO-REPLY
Calendar Properties
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"TODO-REPLY"
PROFILE- A, Value must be "0.9".
VERSION
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
Dawson 54 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
ATTACH X
ATTENDEE A, Value is an RFC822 mailbox
address for C&S capability.
STATUS parameter MUST be
either ACCEPT or DECLINE or
COMPLETED.
CATEGORIES X
CLASS X
COMMENT S, Text value. Provides a
comment from the originator of
the reply to the attendees
concerning the to-do reply
notice.
CREATED X
COMPLETED A, if a TODO-REPLY to indicate
completion of a task. Value is
of the ISO 8601 complete
representation, basic format
of a UTC based date and time.
This is the time the task was
completed.
DESCRIPTION X
DUE X
DURATION X
DTEND X
DTSTART X
EXDATE X
EXRULE X
LAST-MODIFIED X
LOCATION X
PRIORITY X
RELATED-TO X
REQUEST- A, One of the value from the
STATUS table below.
Dawson 55 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
RDATE X
RRULE X
RESOURCES X
RESPONSE- A if not zero
SEQUENCE
SEQUENCE A if not zero
STATUS S, Value may only be NEEDS
ACTION or COMPLETED. This
property is used to confirm to
the originator the status of
the to-do.
SUMMARY X
TRANSP X
URL S
UID A, Must be the UID of the
TODO-REQUEST associated 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 Component Properties
Freebusy component is excluded
from this messge type
Non-standard Properties
X-token S, Recipient may choose to
ignore those non-standard
properties, specified as
optional.
The REQUEST-STATUS property may include the following values:
Dawson 56 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Short Return Longer Return Status Offending Data
Status Description
0 Success. None.
10 Success, but fallback
taken on one or more may be specified. Property name and value
property values.
11 Success, invalid Property name may be
property ignored. specified.
12 Success, invalid Property parameter name
property parameter and value may be
ignored. specified.
13 Success, unknown non- Non-standard property
standard property name may be specified.
ignored.
14 Success, unknown non-
standard property value standard value may be Property and non-
ignored. specified.
15 Success, invalid Calendar component
calendar component sentinel (e.g.,
ignored. "BEGIN:ALARM") may be
specified.
16 Success, request Original and forwarded
forwarded to calendar RFC822 addresses may be
user. specified.
18 Success, truncated end DTEND property value may
date/time to date be specified.
boundary.
19 Success, repeating to-do RRULE or RDATE property
ignored. Scheduled as a name and value may be
single to-do. specified.
100 Invalid property name. Property name may be
specified.
101 Invalid property value. Property name and value
may be specified.
102 Invalid property Property parameter name
parameter. and value may be
specified.
Dawson 57 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
103 Invalid property Property parameter name
parameter value. and value may be
specified.
104 Invalid calendar Calendar component
component sequence. sentinel may be
specified (e.g.,
BEGIN:TIMEZONE).
201 Invalid date or time. Date/time value(s) may
be specified.
202 Invalid rule. Rule value may be
specified.
203 Request not supported. Profile property value
may be specified.
204 Invalid calendar user. Attendee property value
may be specified.
302 Request not supported. PROFILE property value
may be specified.
401 Service unavailable. ATTENDEE property value
may be specified.
402 Invalid calendar ATTENDEE property value
service. may be specified.
403 Invalid calendar user. ATTENDEE property value
may be specified.
404 No scheduling support ATTENDEE property value
for user. may be specified.
405 No authority. PROFILE and ATTENDEE
property values may be
specified.
6.10 TODO-CANCEL
This message type is used to send a cancellation notice for an
existing to-do request to the attendees. The message is sent by the
to-do OWNER or ORGANIZER to the recipients of the original event
request. The OWNER and ORGANIZER are ROLE parameter values for the
ATTENDEE property.
Dawson 58 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
TODO-CANCEL
Calendar Properties
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"EVENT-CANCEL"
PROFILE- A, Value must be "0.9".
VERSION
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 X
ATTENDEE X
CATEGORIES X
CLASS X
COMMENT S, Text value. Provides a
comment from the originator of
the reply to the attendees
concerning the to-do reply
notice.
CREATED X
COMPLETED X
DESCRIPTION X
DUE X
DURATION X
DTEND X
Dawson 59 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
DTSTART X
EXDATE X
EXRULE X
LAST-MODIFIED X
LOCATION X
PRIORITY X
RELATED-TO X
REQUEST- X
STATUS
RDATE X
RRULE X
RESOURCES X
RESPONSE- X
SEQUENCE
SEQUENCE X
STATUS X
SUMMARY X
TRANSP X
URL S
UID A, Must be the UID of the
TODO-REQUEST associated with
the cancelation notice.
Journal Component Properties
Journal component is excluded
from this message type.
Alarm Properties
Alarm component is excluded
from this message type.
Freebusy Properties
Dawson 60 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Freebusy component is excluded
from this message type.
Non-standard Properties
X-token S, But recipient may choose to
ignore those non-standard
properties, specified as
optional.
6.11 JOURNAL-REQUEST
This message type is used to send a request to append a journal entry
to one or more recipients. The message is sent from an originator
(i.e., ROLE=OWNER or ORGANIZER) of a journal request to one or more
intended recipients (ROLE=ATTENDEE). The OWNER and OGANIZER are ROLE
parameter values for the ATTENDEE property.
A journal may note be defined as recurring.
This usage profile does not provide support the capability to cancel
or redefine a journal entry.
JOURNAL-REQUEST
Calendar Properties
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"TODO-REQUEST"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
CREATED S
DAYLIGHT S
DTSTART A
DTEND S
Dawson 61 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
RDATE S, Either RDATE or RRULE may
be specified, but not both.
RRULE S, Either RDATE or RRULE may
be specified, but not both.
TZNAME S
TZOFFSET A
TZTRANS S
UID S
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
ATTACH S
ATTENDEE A
CATEGORIES S
CLASS S
CREATED S
DESCRIPTION A
DTSTART A
LAST-MODIFIED S
RELATED-TO S
RESPONSE S
RESPONSE- S
SEQUENCE
UID A
URL S
Dawson 62 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Alarm Component Properties
Alarm component is excluded
from this message type.
Freebusy Component Properties
Freebusy component is excluded
from this message type.
Non-standard Properties
X-token S, but recipient may choose to
ignore those non-standard
properties, specified as
optional.
6.12 JOURNAL-REPLY
This message type is used to reply to a journal request in order to
update the recipient's acceptance of the request. The message is sent
from a recipient of a journal request back to the to-do ORGANIZER.
If an ORGANIZER is not specified on the request, then the message is
sent to the OWNER.
This profile is ONLY USED to reply to journal request; in order to
ACCEPT or DECLINE it.
JOURNAL-REPLY
Calendar Properties
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"TODO-REPLY"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
Timezone component is excluded
from this message type.
Dawson 63 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
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
ATTACH X
ATTENDEE A
CATEGORIES X
CLASS S
DESCRIPTION A
DTSTART X
LAST-MODIFIED X
RELATED-TO X
RESPONSE S
RESPONSE- S
SEQUENCE
UID A
URL X
Alarm Component Properties
Alarm component is excluded
from this message type.
Freebusy Component Properties
Freebusy component is excluded
from this messge type
Non-standard Properties
X-token S, Recipient may choose to
ignore those non-standard
properties, specified as
Dawson 64 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
optional.
The REQUEST-STATUS property may include the following values:
Short Return Longer Return Status Offending Data
Status Description
0 Success. None.
10 Success, but fallback Property name and value
taken on one or more may be specified.
property values.
11 Success, invalid Property name may be
property ignored. specified.
12 Success, invalid Property parameter name
property parameter and value may be
ignored. specified.
13 Success, unknown non- Non-standard property
standard property name may be specified.
ignored.
14 Success, unknown non- Property and non-
standard property value standard value may be
ignored. specified.
15 Success, invalid Calendar component
calendar component sentinel (e.g.,
ignored. "BEGIN:ALARM") may be
specified.
16 Success, request Original and forwarded
forwarded to calendar RFC822 addresses may be
user. specified.
100 Invalid property name. Property name may be
specified.
101 Invalid property value. Property name and value
may be specified.
102 Invalid property Property parameter name
parameter. and value may be
specified.
Dawson 65 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
103 Invalid property Property parameter name
parameter value. and value may be
specified.
104 Invalid calendar Calendar component
component sequence. sentinel may be
specified (e.g.,
BEGIN:TIMEZONE).
201 Invalid date or time. Date/time value(s) may
be specified.
202 Invalid rule. Rule value may be
specified.
203 Request not supported. Profile property value
may be specified.
204 Invalid calendar user. Attendee property value
may be specified.
302 Request not supported. PROFILE property value
may be specified.
401 Service unavailable. ATTENDEE property value
may be specified.
402 Invalid calendar ATTENDEE property value
service. may be specified.
403 Invalid calendar user. ATTENDEE property value
may be specified.
404 No scheduling support ATTENDEE property value
for user. may be specified.
405 No authority. PROFILE and ATTENDEE
property values may be
specified.
6.13 BUSY-REQUEST
This message type is used to request a busy time from one or more
people. This message only permits requests for busy time information.
The message is sent from an originator (i.e., ROLE=OWNER or
ORGANIZER) of an free/busy time request to one or more intended
recipients (i.e., ROLE=ATTENDEE).
Dawson 66 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
BUSY-REQUEST
Calendar Properties
GEO S
PRODID A
VERSION A, Value must be "2.0".
PROFILE A,"BUSY-REQUEST"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
CREATED S
DAYLIGHT S
DTSTART A
DTEND S
RDATE S, Either RDATE or RRULE may
be specified, but not both.
RRULE S, Either RDATE or RRULE may
be specified, but not both.
TZNAME S
TZOFFSET A
TZTRANS S
UID S
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
Dawson 67 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
from this message type.
Alarm Component Properties
Alarm component is excluded
from this message type.
FreeBusy Component Properties
ATTENDEE A, Value is an RFC822 mailbox
address for C&S capability. An
instance must be specified for
the originator and the
intended recipients of the
request.
COMMENT X
CREATED X
DURATION X
DTEND A, This is the end of the busy
time period being requested.
DTSTART A, This is the start of the
busy time period being
requested.
FREEBUSY X
LAST-MODIFIED X
RELATED-TO X
REQUEST- X
STATUS
RESPONSE- X, The value will always be
SEQUENCE zero.
SEQUENCE X, the value will always be
zero
UID A, Must be referenced by the
recipients in their FREEBUSY-
REPLY message.
URL X
Non-standard Properties
Dawson 68 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
X-token S, but recipient may choose to
ignore those non-standard
properties, specified as
optional.
6.14 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 before yesterday's busy time
information. And the busy time for this half hour SHOULD appear
before 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 S
PRODID A
Dawson 69 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
VERSION A, Value must be "2.0".
PROFILE A,"BUSY-REPLY"
PROFILE- A, Value must be "0.9".
VERSION
Timezone Component Properties
CREATED S
DAYLIGHT S
DTSTART A
DTEND S
RDATE S, Either RDATE or RRULE may
be specified, but not both.
RRULE S, Either RDATE or RRULE may
be specified, but not both.
TZNAME S
TZOFFSET A
TZTRANS S
UID S
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
Dawson 70 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
ATTENDEE A, Value is an RFC822 mailbox
address for C&S capability.
Must be the address of the
recipient replying.
COMMENT S, Text value. Provides a
comment from the originator of
the reply to the recipient
concerning the busytime reply
notice.
CREATED S
DURATION X
DTEND S, Value is the ISO 8601
complete representation, basic
format of a UTC based date and
time. Represents the end of
the busy time period defined
by the BUSYTIME properties in
the Freebusy component.
DTSTART S, Value is the ISO 8601
complete representation, basic
format of a UTC based date and
time. Represents the start of
the busy time period defined
by the BUSYTIME properties in
the Freebusy component.
FREEBUSY A, 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 S
RELATED-TO S, Refers to a related
Freebusy component.
REQUEST- A, One of the values from the
STATUS table below. Multiple
instances of the property may
be specified.
RESPONSE- X, Will always be zero.
Dawson 71 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
SEQUENCE
SEQUENCE X, Will always be zero
UID A, Must be the UID of the
BUSY-REQUEST associated with
the reply.
URL S, Specifies the URL for HTTP
access to a "VCS" file
containing iCalendar Object
with busy time information.
Non-standard Properties
X-token S, Recipient may choose to
ignore those non-standard
properties, specified as
optional.
The REQUEST-STATUS property may include the following values:
Short Return Longer Return Status Offending Data
Status Description
0 Success. None.
10 Success, but fallback Property name and value
taken on one or more may be specified.
property values.
11 Success, invalid Property name may be
property ignored. specified.
12 Success, invalid Property parameter name
property parameter and value may be
ignored. specified.
13 Success, unknown non- Non-standard property
standard property name may be specified.
ignored.
14 Success, unknown non- Property and non-
standard property value standard value may be
ignored. specified.
15 Success, invalid Calendar component
Dawson 72 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
calendar component sentinel (e.g.,
ignored. "BEGIN:ALARM") may be
specified.
16 Success, request Original and forwarded
forwarded to calendar RFC822 addresses may be
user. specified.
18 Success, truncated end
date/time to date be specified. DTEND property value may
boundary.
100 Invalid property name. Property name may be
specified.
101 Invalid property value. Property name and value
may be specified.
102 Invalid property Property parameter name
parameter. and value may be
specified.
103 Invalid property Property parameter name
parameter value. and value may be
specified.
104 Invalid calendar Calendar component
component sequence. sentinel may be
specified (e.g.,
BEGIN:TIMEZONE).
201 Invalid date or time. Date/time value(s) may
be specified.
203 Invalid request. Profile property value
may be specified.
204 Invalid calendar user. Attendee property value
may be specified.
302 Request not supported. PROFILE property value
may be specified.
401 Service unavailable. ATTENDEE property value
may be specified.
402 Invalid calendar ATTENDEE property value
service. may be specified.
403 Invalid calendar user. ATTENDEE property value
may be specified.
Dawson 73 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
404 No scheduling support ATTENDEE property value
for user. may be specified.
405 No authority. PROFILE and ATTENDEE
property values may be
specified.
7. MIME Message Format Binding
The iMIP is applicable to many transports; including vendor-specific
electronic messaging formats, standards based electronic messaging
formats such as the IETF SMTP/MIME, file system, common memory
exchange such as a clipboard, drag/drop protocols, Infra-red Data
Association (IrDA) object exchange, wireless pagers, etc.
This section defines the message binding to the MIME electronic mail
transport.
7.1 MIME Media Type
A MIME entity containing content information formatted according to
this design document will be referenced as a "text/calendar" content
type. It is assumed that this content type will be transported
through a MIME electronic mail transport.
7.2 Security
When transported over SMIME, these messages should utilize the SMIME
signature to prevent spoofing.
7.3 RFC 822 Addresses
The calendar address specified within the ATTENDEE property in a
iCalendar object MUST be a fully qualified, RFC 822 address for the
corresponding OWNER, ORGANIZER or ATTENDEE of the event or to-do. The
address MUST be the RFC 822 address for the calendaring and
scheduling mail box for the attendee. This may or may not be the same
mail box that the individual uses for interpersonal messaging (i.e.,
email). The proper RFC 822 address will need to be identified and put
into the ATTENDEE property by the calendaring and scheduling service.
This information can not be assumed to be set by the electronic
messaging MTA.
A UA using MIME messages conforming to this design document may have
different RFC 822 addresses for their electronic mail post office and
the mail box used for calendaring and scheduling. In such cases, the
addresses in the MIME header fields (e.g., To, From, Cc, Bc, Reply-
to, etc.) may be different than the RFC 822 addresses specified in
the ATTENDEE properties within the iCalendar object.
Dawson 74 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
7.4 Content Type
A MIME body part containing content information that conforms with
this design document MUST have a Content-Type value of
"text/calendar". The content type header field MUST also include the
type parameter "profile". The parameter value MUST be one of the
message types defined by this profile. The value MUST also be the
same as the value of the PROFILE calendar property within the
iCalendar object. This means that if a MIME message contains multiple
iCalendar objects, then they must be further encapsulated with a
"multipart/mixed" MIME entity. This will allow each of the iCalendar
objects to be encapsulated within their own "text/calendar" MIME
entity.
If the iMIP based message is not an immediate child of the root MIME
message entity, then it should be assumed to be a part of a forwarded
message. It may be ignored.
The Content-Type CHARSET parameter MUST also appear in any MIME
entity encapsulating a iCalendar object conforming to this design
document. The CHARSET parameter value MUST be "UTF-8" in order to
override the default of "US-ASCII".
The following is an example of this header field with a value that
indicates an event request message.
CONTENT-TYPE:text/calendar; profile=event-request;
charset=UTF-8
The "text/calendar" may be included as a MIME entity within either a
"multipart/mixed" or "multipart/alternative" multi-part MIME message.
This will allow the scheduling message type to be included in a MIME
message with other content information (i.e., multipart/mixed) or
included in a MIME message with a clear-text, human-readable form of
the scheduling message (i.e., multipart/alternative).
In order to permit the information in the scheduling message to be
understood by MIME user agents (UA) that do not support the
text/calendar content type, scheduling messages should be sent with
an alternative, human-readable form of the information.
[Editor's Note: An example is needed here.]
7.5 Content-Transfer-Encoding
The new Content-Transfer-Encoding header field was added in
[RFC2045]. This header field specifies the encoding used to transform
the content information into the MIME canonical content format.
All MIME entities formatted according to this design document must be
"8bit". This is to allow transfer of UTF-8 character set encoded
iCalendar objects. The [RFC2045] default is "7bit". Hence, each MIME
entity encapsulating a iCalendar object must include this header
Dawson 75 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
field. The following is an example of how this header field must
appear.
CONTENT-TRANSFER-ENCODING:8bit
7.6 Content-Description
The Content-Description header field is used to provide a human-
readable explanation to the MIME entity. This is a useful field to
record the fact that the content information is a iCalendar object.
A MIME entities formatted according to this design document that
includes this header field SHOULD have it's value prefixed with the
text "X-iCAL:".
7.7 To
Any of the attendees addressed by the iCalendar object, that are also
addressable with Internet SMTP addresses, should have their RFC 822
addresses included in the TO header field. An attendee that is
included in the iCalendar object but not in the TO header field is
still a valid attendee to the event or to-do.
7.8 From
The originator of the iCalendar object should have their address in
the value of the To header field. This may not be possible for
iCalendar objects reflected from a mailing list.
7.9 Cc and Bc
Event or to-do attendees may be specified in the CC header field.
This does not imply any special or limited role for the attendee.
7.10 Reply-To
The RFC 822 address of the originator of the iMIP MIME message should
be specified as the value of the REPLY-TO header field. This will
allow an electronic mail reply to the originator from the recipients
of the iCalendar object.
7.11 Subject
The SUBJECT header field SHOULD be prefixed with the text "X-iCAL:"
in order to allow the message to be detected as a iMIP by legacy
systems. A MIME UA written to conform to this design document will
use the Content-Type value and Profile parameter value as a primary
means of detection.
8. Alternate Plain-text Messages
Some intended attendees for events or to-dos may be using a
traditional, plain-text email user agent. They may not being using a
calendaring and scheduling application that supports the iCalendar
Dawson 76 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Object. In such cases, a plain-text rendering of the iCalendar Object
message would allow minimal support for some of the scheduling
features defined by this document. The following formats are intended
to be used to for this purpose. These alternative messages may be
sent in a "multipart/alternative" MIME media type.
8.1 EVENT-REQUEST, RSVP=YES
The following is an alternative, plain-text message for an EVENT-
REQUEST message, where a reply is requested. The SUBJECT property
value SHOULD be the same as the event summary or the first 255
character of the event description.
<substitute organizer/owner name> is inviting you to a meeting as
described below the line. Please put an "XXX" on the appropriate line
below (and fill in any other necessary information) and then reply
with this message to <substitute organizer/owner email address>.
_____ ACCEPT: I will attend this meeting.
_____ DECLINE: I will not attend this meeting.
_____ TENTATIVE: I do not now know whether I will attend this
meeting.
_____ DELEGATE: I will not attend this meeting -- I am inviting
the following delegate and sending this message to
him/her: _______________________
_____ PROPOSE ANOTHER TIME: I would like to attend this meeting
but propose moving it to the following date and time:
Date: ___________
Time: ___________
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Event ID: <substitute UID for event>
Meeting Summary: <substitute event summary>
Start Date/Time: <substitute event start date/time>
End Date/Time: <substitute event end date/time>
Recurring Date(s): <"None" or substitute recurring dates/times>
Location: <substitute event location>
Description: <substitute event description>
Invitees: <substitute list of attendees>
8.2 EVENT-REQUEST, RSVP=NO
The following is an alternative, plain-text message for an EVENT-
REQUEST message, where a reply is NOT requested. The SUBJECT property
Dawson 77 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
value SHOULD be the same as the event summary or the first 255
character of the event description.
<substitute organizer/owner name> is inviting you to a meeting as
described below the line. There is no need to reply to this message,
but please come to the meeting if you can.
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Event ID: <substitute UID for event>
Meeting Summary: <substitute event summary>
Start Date/Time: <substitute event start date/time>
End Date/Time: <substitute event end date/time>
Recurring Date(s): <"None" or substitute recurring dates/times>
Location: <substitute event location>
Description: <substitute event description>
Invitees: <substitute list of attendees>
8.3 EVENT-REQUEST, EXPECT=REQUIRED
The following is an alternative, plain-text message for an EVENT-
REQUEST message, where the attendee's attendance is required. This
alternative message can also be used when the attendee's reply is
requested (i.e., RSVP=YES). The SUBJECT property value SHOULD be the
same as the event summary or the first 255 character of the event
description.
<substitute organizer/owner name> is inviting you to a meeting as
described below the line. Your attendance is required in order for
this meeting to take place. Please put an "XXX" on the appropriate
line below (and fill in any other necessary information) and then
reply with this message to <substitute organizer/owner email
address>.
_____ ACCEPT: I will attend this meeting.
_____ DECLINE: I will not attend this meeting.
_____ TENTATIVE: I do not now know whether I will attend this
meeting.
_____ DELEGATE: I will not attend this meeting -- I am inviting
the following delegate and sending this message to
him/her: _______________________
_____ PROPOSE ANOTHER TIME: I would like to attend this meeting
but propose moving it to the following date and time:
Date: ___________
Time: ___________
Dawson 78 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Event ID: <substitute UID for event>
Meeting Summary: <substitute event summary>
Start Date/Time: <substitute event start date/time>
End Date/Time: <substitute event end date/time>
Recurring Date(s): <"None" or substitute recurring dates/times>
Location: <substitute event location>
Description: <substitute event description>
Invitees: <substitute list of attendees>
8.4 EVENT-CANCEL
The following is an alternative, plain-text message for an EVENT-
CANCEL message. The SUBJECT property value SHOULD be the same as the
event summary or the first 255 character of the event description.
<substitute organizer/owner name> is canceling the meeting described
below the line. Please remove it from your personal calendar. There
is no need to reply to this message.
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Event ID: <substitute UID for event>
Meeting Summary: <substitute event summary>
Start Date/Time: <substitute event start date/time>
End Date/Time: <substitute event end date/time>
Location: <substitute event location>
Description: <substitute event description>
Invitees: <substitute list of attendees>
8.5 EVENT-REPLACE, RSVP=YES
The following is an alternative, plain-text message for an EVENT-
REPLACE message, where a reply is requested. The SUBJECT property
Dawson 79 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
value SHOULD be the same as the event summary or the first 255
character of the event description.
<substitute organizer/owner name> has changed the characteristics of
this meeting. The meeting details are described below this line.
Please put an "XXX" on the appropriate line below (and fill in any
other necessary information) and then reply with this message to
<substitute organizer/owner email address>.
_____ ACCEPT: I will attend this meeting.
_____ DECLINE: I will not attend this meeting.
_____ TENTATIVE: I do not now know whether I will attend this
meeting.
_____ DELEGATE: I will not attend this meeting -- I am inviting
the following delegate and sending this message to
him/her: _______________________
_____ PROPOSE ANOTHER TIME: I would like to attend this meeting
but propose moving it to the following date and time:
Date: ___________
Time: ___________
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Event ID: <substitute UID for event>
Meeting Summary: <substitute event summary>
Original Start Date/Time: <substitute event start date/time>
Original End Date/Time: <substitute event end date/time>
Original Recurring Date(s): <"None" or substitute recurring
dates/times>
NEW Start Date/Time: <substitute event start date/time>
NEW End Date/Time: <substitute event end date/time>
NEW Recurring Date(s): <"None" or substitute recurring dates/times>
NEW Location: <substitute event location>
NEW Description: <substitute event description>
Invitees: <substitute list of attendees>
8.6 EVENT-DECLINECOUNTER
The following is an alternative, plain-text message for an EVENT-
DECLINECOUNTER. The SUBJECT property value SHOULD be the same as the
event summary or the first 255 character of the event description.
<substitute organizer/owner name> has declined your proposed change
to the date and/or time for this meeting. Your proposed changes are
detailed below the line.
Dawson 80 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Event ID: <substitute event UID>
Meeting Summary: <substitute event summary>
Start Date and Time: <substitute event start date/time>
End Date and Time: <substitute event end date/time>
Location: <substitute event location>
Description: <substitute event description>
Invitees: <substitute list of attendees>
8.7 EVENT-DELEGATE, RSVP=YES
The following is an alternative, plain-text message for an EVENT-
DELEGATE message, where a reply is requested. The SUBJECT property
value SHOULD be the same as the event summary or the first 255
character of the event description.
<substitute delegator's name> has requested that you be their
delegate at a meeting as described below the line. Please put an
"XXX" on the appropriate line below (and fill in any other necessary
information) and then reply with this message to <substitute event
organizer/owner email address> and <substitute delegator's email
address>.
_____ ACCEPT: I will attend this meeting.
_____ DECLINE: I will not attend this meeting.
_____ TENTATIVE: I do not now know whether I will attend this
meeting.
_____ DELEGATE: I will not attend this meeting -- I am inviting
the following delegate and sending this message to
him/her: _______________________
_____ PROPOSE ANOTHER TIME: I would like to attend this meeting
but propose moving it to the following date and time:
Date: ___________
Time: ___________
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Event ID: <substitute UID for event>
Meeting Summary: <substitute event summary>
Start Date/Time: <substitute event start date/time>
End Date/Time: <substitute event end date/time>
Dawson 81 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Location: <substitute event location>
Description: <substitute event description>
Invitees: <substitute list of attendees>
8.8 TODO-REQUEST, RSVP=YES
The following is an alternative, plain-text message for an TODO-
REQUEST message, where a reply is requested. The SUBJECT property
value SHOULD be the same as the event summary or the first 255
character of the event description.
<substitute organizer/owner name> is requesting you to do the task(s)
as described below the line. Please put an "XXX" on the appropriate
line below (and fill in any other necessary information) and then
reply with this message to <substitute organizer/owner email
address>.
_____ ACCEPT: I will do this task.
_____ DECLINE: I will not do this task.
_____ DELEGATE: I will not do this task -- I am delegating
the task and sending this message to
him/her: _______________________
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Event ID: <substitute UID for to-do>
To-do Summary: <substitute to-do summary>
Start Date/Time: <substitute to-do start date/time>
Due Date/Time: <substitute to-do end date/time>
Recurring Due Date(s): <"None" or substitute recurring dates/times>
Priority: <substitute to-do priority>
Description: <substitute to-do description>
Invitees: <substitute list of attendees>
8.9 TODO-REQUEST, RSVP=NO
The following is an alternative, plain-text message for an TODO-
REQUEST message, where a reply is NOT requested. The SUBJECT property
value SHOULD be the same as the event summary or the first 255
character of the event description.
Dawson 82 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
<substitute organizer/owner name> is requesting you to do the task(s)
as described below the line.
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Event ID: <substitute UID for to-do>
To-do Summary: <substitute to-do summary>
Start Date/Time: <substitute to-do start date/time>
Due Date/Time: <substitute to-do end date/time>
Recurring Due Date(s): <"None" or substitute recurring dates/times>
Priority: <substitute to-do priority>
Description: <substitute to-do description>
Invitees: <substitute list of attendees>
8.10 TODO-CANCEL
The following is an alternative, plain-text message for an TODO-
CANCEL message. The SUBJECT property value SHOULD be the same as the
todo summary or the first 255 character of the to-do description.
<substitute organizer/owner name> is canceling the to-do described
below the line. Please remove it from your personal calendar. There
is no need to reply to this message.
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
To-do ID: <substitute UID for event>
To-do Summary: <substitute to-do summary>
Start Date/Time: <substitute to-do start date/time>
End Date/Time: <substitute to-do end date/time>
Location: <substitute event location>
Description: <substitute event description>
Invitees: <substitute list of attendees>
Dawson 83 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
8.11 JOURNAL-REQUEST, RSVP=YES
The following is an alternative, plain-text message for an JOURNAL-
REQUEST message, where a reply is requested. The SUBJECT property
value SHOULD be the first 255 character of the event description.
<substitute organizer/owner name> is requesting you add the journal
entry as described below the line. Please put an "XXX" on the
appropriate line below (and fill in any other necessary information)
and then reply with this message to <substitute organizer/owner email
address>.
_____ ACCEPT: I will do this journal entry.
_____ DECLINE: I will not do this journal entry.
_____ DELEGATE: I will not do this journal entry -- I am
delegating the journal entry and sending this message
to him/her: _______________________
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Journal ID: <substitute UID for journal>
Journal Summary: <substitute journal summary>
Start Date/Time: <substitute journal start date/time>
Description: <substitute journal description>
8.12 JOURNAL-REQUEST, RSVP=NO
The following is an alternative, plain-text message for an JOURNAL-
REQUEST message, where a reply is NOT requested. The SUBJECT property
value SHOULD be the first 255 character of the event description.
<substitute organizer/owner name> is requesting you add the journal
entry as described below the line.
Attached Files: <substitute file URL for attachment>
DO NOT MODIFY ANYTHING BELOW THIS LINE
_____________________________________________________________________
Journal ID: <substitute UID for journal>
Journal Summary: <substitute journal summary>
Start Date/Time: <substitute journal start date/time>
Dawson 84 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
Description: <substitute journal description>
9. IrDA Binding
TBD. Initial text to be provided by Frank Dawson
10. TCP LAN Protocol Binding
TBD. Initial text to be provided by John Rose
11. SPX LAN Protocol Binding
TBD. Initial text to be provided by John Rose
12. Desktop Interaction Requirements
This section defines the minimal UI function client products MUST
support in order to conform to this design document.
12.1 Clipboard
Applications conforming to this design document MUST provide the
Edit-Copy or Edit-CopySpecial menu option and a smarticon to permit
the end-user to copy a selected event or to-do to the operating
system clipboard as a iCalendar object.
The iCalendar object MUST be copied to the clipboard both as a
iCalendar identifiable clipboard object and as a formatted-text
clipboard object. This will allow copying of the iCalendar object to
simple applications that just support formatted text clipboard
objects.
Applications conforming to this design document also MUST provide
Edit-Paste or Edit-PasteSpecial menu option and a smarticon to permit
the end-user to paste a clipboard based iCalendar object into the
application.
If the application does not find a iCalendar tagged object on the
clipboard, it MUST try to find the iCalendar object in a simple
formatted-text object on the clipboard. This will allow the
application to interoperate with simple applications that support
formatted-text clipboard representation of iCalendar objects but not
yet support iCalendar tagged clipboard objects.
12.2 Drag/Drop
Applications conforming to this design document that runs in an
environment with drag/drop MUST provide drag/source protocol support
for the rendering an event or to-do as a iCalendar.
Dawson 85 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
In addition, an application conforming to this design document that
runs in an environment with drag/drop MUST provide drop/target
protocol support for the import of a iCalendar object.
If the operating system environment supports both a clipboard and
file system based drag/drop protocol, then both of these modes MUST
be supported for both drag/source and drag/target.
12.3 File System
Applications conforming to this design document MUST provide the
File-SaveAs menu option and a smarticon to permit the end-user to
export a selected event or to-do into the file system as a iCalendar
object. The default file type MUST be "VCS". File systems that do not
reply on file extensions may need alternative default extensions.
Applications also MUST provide the File-Open menu option and a
smarticon to permit the end-user to import a selected iCalendar
object into the application.
12.4 IrDa Communications
Applications conforming to this design document SHOULD provide both
the File-Send menu option and a iCalendar send smarticon to permit
the end-user to "beam" a selected event or to-do over an operational
IrDA communications port.
The iCalendar "send" icon is available in a number of sizes and color
densities from the http://www.imc.org/pdi web site.
13. Conformance
Applications conforming to this design document must meet the
following minimum requirements:
. Conform to the minimum requirements defined by the [ICAL]
specification;
. Also comply with the Mandatory requirements defined by this
design document;
. and optionally comply with any Optional requirements defined
by this design document.
14. References
[ID-CSP] "MIME Calendaring and Scheduling Content Type Profile",
Internet-Draft, November 26, 1996, ftp://ftp.ietf.org/internet-
drafts/draft-ietf-calsch-csp-00.txt or http://www.imc.org/draft-ietf-
calsch-csp.
[ID-DT] "Date and Time on the Internet", Internet-Draft, December
1996, http://www.imc.org/draft-newman-datetime.
Dawson 86 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
[ICAL] "Internet Calendaring and Scheduling Core Object Specification
- iCalendar", Internet-Draft, February 3, 1997,
ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-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.
[VCAL] "vCalendar - The Electronic Calendaring and Scheduling Format
- Version 1.0", Versit Consortium, September 18, 1996,
http://www.imc.org/pdi/vcal-10.doc.
[VCARD] "vCard - The Electronic Business Card Exchange Format -
Version 2.1", Versit Consortium, September 18, 1996,
http://www.imc.org/pdi/vcard-21.doc.
[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.
15. Acknowledgements
The following individuals have made significant contributions to this
document:
John Banks-Binici, Polly Brown, Doug Conmy, Susan Esher, Arvind
Goyal, Ryan Jansen, Bruce Kahn, Leo Parker, John Rose, Vinod
Seraphin, Gail Strait.
16. Author's Address
The following address information is provided in a vCard v2.1,
Electronic Business Card, format.
BEGIN:VCARD
ORG:Lotus Development Corporation
FN:Frank Dawson
Dawson 87 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;
Raleigh;NC;27613-3502;USA
TEL;WORK;PREF;MSG:+1-919-676-9515
TEL;WORK;MSG:+1-617-693-8728
TEL;WORK;FAX:+1-919-676-9564
EMAIL;INTERNET;PREF:Frank_Dawson@lotus.com
EMAIL;INTERNET:fdawson@earthlink.net
URL;HOME:http://home.earthlink.net/~fdawson
END:VCARD
17. Issues
The following discussion relates to open design issues remained open
when this version of the design document was completed.
1. Need to resolve how to specify correct ATTENDEE values within a
given product. A message may be transferred through a transport
gateway. The address formats and content may be changed prior to
recipient. In such cases, how is the recipient going to be able to
reply to the originator? How is the originator going to be able to
insert the ATTENDEE values into the message such that they are
useful to the recipient?
2. Request to UI for a human readable, "pretty" message counterpart
to each of the messages. This needs to include a section with a
text "response form" (e.g., check this box to provide a confirm
reply).
3. Binding to MIME multipart/alternative, multipart/related, and what
to do for single body part.
4. Do we allow a recipient to offer a counter proposal (i.e., EVENT-
COUNTER) to an EVENT-REQUEST that describes a recurring event?
5. Need a LAN binding for both TCP, AppleTalk, and SPX protocols (to
be provided by John Rose/cc:Mail and John Cabot/Iris).
6. Do we need a ROOM value for ATTENDEE;TYPE parameter.
7. Should we be using a common vCard/iCalendar parser code base.
18. Resolutions
1. Implementation MUST be able to receive any message defined by this
design document. Implementations MAY provide behaviors for a
subset of the range of capabilities defined by this document
(e.g., Might not put alarms in EVENT-REQUEST or Might ignore alarm
properties in received EVENT-REQUEST messages). Implementations
MUST not reject a message because of minimal support for the event
or to-do description.
2. ATTENDEE property values MUST be a fully qualified, RFC 822
address.
Dawson 88 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
3. Group scheduled to-dos MUST be supported. Both the TODO-REQUEST
and TODO-REPLY message types MUST be supported.
4. Implementations that do not support SUMMARY property MUST append
the value to the DESCRIPTION property value.
5. Implementations MUST store values for optional properties that
they don't support. However, they may not act on these values.
Optional, non-standard properties may be ignored by
implementations that do not support the function.
6. Implementations SHOULD include a text prefix of "X-iCAL:" in the
Subject and Content-Description MIME header fields in order to
allow legacy SMTP recipient to better handle text/calendar MIME
message types.
7. There are minimum length requirements for some properties by
recipients of messages. For instance, a minimum of 4094 bytes MUST
be supported by recipient for text values for the DESCRIPTION and
COMMENT properties. A minimum of 254 bytes MUST be supported by
recipients for text values for the SUMMARY property. Additional
requirements for other properties may be identified later.
Recipients MAY truncate longer property values.
8. The C&S message is formatted as two alternative representations,
if the message transport supports multiple part body parts. The
initial body part is a pretty text equivalent of the C&S
information. The second body part in the message is the
interoperable message format defined by this design document.
9. Any attachments to the event or to-do request are passed as
secondary attachments. Their content identifiers are specified as
the value for the associated ATTACH property. This assumes a
multiple body part capability in the message transport. If this is
not the case, then the attachments are send as independent
messages. They message identifiers are specified as the value for
the associated ATTACH property.
10. For Internet mapping of messages, the ATTENDEE value needs to be
the Internet RFC822 address for the mail box that receives C&S
messages. For most people, this is the same as email address. This
value DOES NOT include any comment texts, as specified in RFC 822.
11. Person schema needs to provide flexibility for specifying a
different email address for C&S. It should also specify a URL for
busy time lookup.
12. Allow event description (i.e., DTSTART, DTEND) to span day-
boundary. The fallback for recipients that do not support this is
to truncate the event description to the day-boundary (i.e.,
"T240000" is the DTEND time component of the date/time value). The
remainder of the event duration is lost.
Dawson 89 Expired November 1997
Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
May 1, 1997
13. The EVENT-REQUEST may include additional BEGIN/END:ALTERNATE
calendar components that are the 1st, 2nd, 3rd, etc alternative
times. The alternative ALTERNATE descriptions MUST reference the
primary VEVENT with the REPLY-TO property containing the UID of
the primary VEVENT. ATTENDESS reply with a REPLY message to only
one event description.
14. Local time will be interpreted by a recipient as being relative to
their timezone. Date and time values in the DTSTART, DTEND, DUE,
COMPLETED properties SHOULD be represented as a UTC date/time
value unless they intent is that they be "floating" values.
15. All iCalendar objects MUST use UTF-8 as the default character set.
Dawson 90 Expired November 1997