[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc2447                               
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