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

Versions: 00                                                            
Network Working Group                                  F. Dawson, Lotus
INTERNET-DRAFT                               R. Hopson, ON Technologies
<ietf-calsch-itip-part2-00.txt>                    S. Mansour, Netscape
Expires in six months from July 18, 1997       S. Silverberg, Microsoft


       iCalendar Transport-Independent Interoperability Protocol
                   (iTIP) Part Two: Scheduling To-Dos

Status of this Memo


   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months. Internet-Drafts may be updated, replaced, or made obsolete by
   other documents at any time. It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this document is unlimited.

Abstract


   This set of documents, collectively called the iCalendar Transport-
   independent Interoperability Protocol, or iTIP, defines a transport-
   independent message protocol to allow for searching for busy time and
   the scheduling of events, journals, or journal entries on different
   calendaring and scheduling systems. These documents are based on
   earlier work documented in the iCalendar format. Because iCalendar
   delt mainly with the format of calendaring information and said so
   little about the method for conveying scheduling semantics, these
   documents add scheduling semantics to the base calendaring
   functionality defined in iCalendar.

   The initial document specifies the messages for allowing searching
   for free or busy time information and for scheduling events. The
   second document defines the messages for scheduling to-dos, or action
   items. The third document defines the messages for scheduling journal
   entries. This document set is intended to convey calendaring and
   scheduling semantics between different applications, independent of
   transport. This document is also being offered as a specification for
   demonstrating industry-wide, calendaring and scheduling
   interoperability. The protocol defined by this document is applicable
   for conveying calendaring and scheduling information across any
   reliable transport. This format is useful for both client-to-server
   communication, server-to-server communication, and client-to-client,
   peer communication (e.g., PDA synchronization with a PIM).



Dawson/Hopson/Mansour/Silverberg   1               Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   The breadth of this document is limited to exchanging only the to-do
   type of calendar information. It does not address issues related to
   events or journal entries. Instead, the document outlines a model for
   calendar exchange that defines both static and dynamic to-do objects.
   Static to-do objects are used to transmit to-dos from one entity to
   another without the expectation of continuity or referential
   integrity with the original item. Dynamic to-do objects are a
   superset of static to-do objects and will gracefully degrade to their
   static counterparts for clients that only support static to-do
   objects.














































Dawson/Hopson/Mansour/Silverberg   2               Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



   Table of Contents:



1. INTRODUCTION........................................................5

 1.1 ITIP SCHEDULING TRANSACTIONS.....................................5

2. PROTOCOL MODELS.....................................................6

 2.1 APPLICATION PROTOCOL.............................................6
  2.1.1 Scheduling Transaction State..................................7
 2.2 ADVANCED CALENDARING CONCEPTS....................................8
 2.3 CALENDAR ROLES...................................................9

3. APPLICATION PROTOCOL ELEMENTS.......................................9

 3.1 ITIP MESSAGE CONFORMANCE........................................10
  3.1.1 Restrictions on DTSTART and DUE..............................11
 3.2 SUMMARY OF APPLICATION PROTOCOL ELEMENTS........................11
  3.2.1 TODO-PUBLISH.................................................11
  3.2.2 TODO-REQUEST.................................................14
  3.2.3 TODO-REPLY...................................................18
  3.2.4 TODO-CANCEL..................................................20
  3.2.5 Rescheduling or Changing a To-do.............................22
  3.2.6 TODO-RESEND..................................................26
 3.3 REQUEST STATUS CODES............................................29

4. EXAMPLES...........................................................31

 4.1 PUBLISHED TO-DOS................................................31
  4.1.1 A Minimal Published To-Do....................................32
  4.1.2 Changing A Published To-Do...................................32
  4.1.3 Canceling A Published To-Do..................................33
  4.1.4 A Rich Published To-Do.......................................33
 4.2 GROUP TO-DO EXAMPLES............................................35
  4.2.1 A To-Do Request..............................................36
  4.2.2 A To-Do Reply................................................36
  4.2.3 Update A To-do...............................................37
 4.3 RECURRING TO-DO AND TIME ZONE EXAMPLES..........................37
  4.3.1 A Recurring To-do That Spans Timezones.......................37
  4.3.2 Creating  an Exception to a Recurring To-Do..................39
  4.3.3 Modify Exception.............................................40
  4.3.4 Cancel an Exception..........................................40
  4.3.5 Cancel Recurring To-Do.......................................41
  4.3.6 Decline A Previously Accepted Exception......................41

5. APPLICATION PROTOCOL FALLBACKS.....................................42

 5.1 ICALENDAR PROFILE TYPES.........................................42
 5.2 CALENDAR COMPONENTS.............................................42
 5.3 CALENDAR PROPERTIES.............................................43
 5.4 COMPONENT PROPERTIES............................................43
 5.5 LATENCY ISSUES..................................................45
  5.5.1 Cancelation of an Unknown To-do..............................45
 5.6 SEQUENCE NUMBER.................................................45

6. SECURITY CONSIDERATIONS............................................45



Dawson/Hopson/Mansour/Silverberg   3               Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


7. ACKNOWLEDGMENTS....................................................46

8. BIBLIOGRAPHY.......................................................46

9. AUTHORS ADDRESSES..................................................47



















































Dawson/Hopson/Mansour/Silverberg   4               Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997





1.   Introduction


   The purpose of this document set is to define the format of iCalendar
   objects and how the iCalendar objects are conveyed between Calendar
   User Agents (CUA) and Calendar Services (CS). This involves the
   definition of a protocol that uses the iCalendar Object as the basis
   for a collection of messages that are transmitted from one
   calendaring system to another. The protocol is transport independent
   but can be bound to either a real-time transport or a store-and-
   forward transport such as e-mail.

   This set of documents is based on the calendaring and scheduling
   model specified in [ICSM].

   The first document in the set specifies the messages for allowing
   searching for free or busy time information and for scheduling
   events. This the second document, defines the messages for scheduling
   to-dos, or action items. The third document defines the messages for
   scheduling journal entries. Implemented as a whole, this document set
   will allow different calendaring and scheduling domains to
   interoperate; allowing for the seach for available free or busy time
   information and scheduling events, to-dos, or daily journal entries.

1.1  iTIP Scheduling Transactions


   The profiles described in section 3 (Application Protocol Elements)
   may be considered usage profiles of the [ICAL] and is designed
   specifically for the exchange of calendaring information between
   scheduling applications.

   To-do Publication

       Publish a to-do;

       Change a published to-do;

       Cancel a published to-do.

   Group To-dos

       Request that a to-do be assigned to one or more recipients;

       Reply to an existing to-do request to accept, decline, or
        indicate completion of the to-do request;

       Allow the organizer of a to-do to cancel the to-do;

       Allow the organizer of a to-do to replace the original to-do
        definition, as when a to-do description is clarified or the
        attendee assignment information is updated;

       Allow an attendee to request a resend of the current
        description for an existing request.

   Recurring To-dos and Timezones





Dawson/Hopson/Mansour/Silverberg   5               Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


       Support scheduling a to-do between individuals in different
        time zones;

       Support for time zones;

       Support for DST rules;

       Create a recurring to-do request with exception dates

2.   Protocol Models


   The protocol model for this part of iTIP is intended to be the same
   as that described in iTIP Part 1. It is repeated here for clarity
   when reading this document alone.

   There are two distinct protocols that comprise iTIP: an Application
   Protocol and a Transport Protocol. The Application Protocol defines
   the content of the iCalendar objects sent between a sender and a
   receiver in order to accomplish the various iTIP scheduling
   transactions (section 1.1). The Transport protocol defines how the
   iCalendar objects are sent between the sender and receiver. This
   document focuses on the Application Protocol. Some considerations for
   Transport Protocol documents are listed in Appendix A of [ITIP-1].

             +----------+                      +----------+
             |          |        iTIP          |          |
             |  Sender  |<-------------------->| Receiver |
             |          |                      |          |
             +----------+                      +----------+

   There are several variations of this diagram in which the Sender and
   Receiver take on various roles of  CUA or CS. These variants are
   detailed in the Model document [ICMS]

   The architecture of iTIP is depicted in the diagram below. An
   application written to this specification may utilize either the
   binding for the store-and-forward transport, the real time transport,
   or both. The iTIP could also be bound to other transports. If a
   capability is not available on a particular transport binding, iTIP
   provides a mechanism for indicating so.

              +------------------------------------------+
              |                 iCalendar                |
              +------------------------------------------+
              |                   iTIP                   |
              +------------------------------------------+
              |Real-time | Store and Fwd | Other         |
              |Transport | Transport     | Transports... |
              +------------------------------------------+

2.1  Application Protocol


   The model for the application protocol is originator-based (organizer
   or owner roles for a request). That is, the originator of a request
   sends it out to one or more invitees. The invitees reply back to the



Dawson/Hopson/Mansour/Silverberg   6               Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   originator. The originator maintains the status of the event. Only
   the originator can modify or cancel the request.

   The data sources for the protocol are the Calendar Users as defined
   in [ICMS]. Examples of these users are the originator (i.e.,
   organizer or owner) and attendees of an iCalendar to-do. The data
   objects are the iCalendar objects that are exchanged between Calendar
   Users.

2.1.1     Scheduling Transaction State


   The state of the to-do scheduling transaction is described by the
   STATUS and ATTENDEE properties in the to-do calendar component.

   If there are no attendees in the calendar component, then this
   implies the publish - state STATUS.

   The state of a to-do request changes from the time it is initially
   assigned, to when the attendees reply to the request, to when each of
   the attendees complete the to-do. When an originator sends out the
   to-do request, it's state with respect to the attendees is NEEDS
   ACTION. If the attendee accepts the assignment, then the status is
   changed to ACCEPTED. If the attendee rejects the assignment, then the
   status is changed to DECLINED. When the attendee completes the to-do,
   then the status is changed to COMPLETED. These changes in the
   attendee status for the to-do are effected by the attendee sending
   the originator a TODO-REPLY message with their updated status.

   The general status of the to-do is reflected by the STATUS property.
   The to-do STATUS property is controlled by the originator. There is
   no default status. Initially, the originator should either set the
   status to TENTATIVE or CONFIRMED. The originator can also set the
   status to CANCELLED by sending a TODO-CANCEL message to the
   attendees. The status is set to COMPLETED when all the attendees for
   the to-do request have indicated their completion of the assignment
   by sending the originator a TODO-REPLY message with their status set
   to COMPLETED.

   The states of the protocol are contained in the iCalendar object. Due
   to the individual nature of a scheduling transaction, the state may
   be different for each Calendar User. The diagram below describes the
   various state changes.














Dawson/Hopson/Mansour/Silverberg   7               Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



          +===========================+==========================
          | Owner / Originator        | Attendee / Recipient    |
          +===========================+=========================+
          |  TODO-PUBLISH ----------------------------------->  |
          |     State=CONFIRMED                                 |
          +=====================================================+
          |  TODO-REQUEST ----------------------------------->  |
          |     State=CONFIRMED | TENTATIVE                     |
          |     Attendee Status=NEEDS ACTION                    |
          |                                                     |
          |  <------------------------------------- TODO-REPLY  |
          |     State=As specified in the TODO-REQUEST message  |
          |     Attendee Status=ACCEPTED | DECLINED | COMPLETED |
          +=====================================================+
          |  TODO-CANCEL  ----------------------------------->  |
          |     State=CANCELLED                                 |
          |     Attendee Status=As specified in the TODO-REPLY  |
          +=====================================================+
          |  TODO-REQUEST ----------------------------------->  |
          |     (A rescheduled or redefined to-do request)      |
          |     State=CONFIRMED | TENTATIVE                     |
          |     Attendee Status=As defined in previous TODO-    |
          |                     REPLY message for this to-do    |
          +=====================================================+
          |  <-------------------------------------TODO-RESEND  |
          |     State=As specified in the TODO-REQUEST message  |
          |     Attendee Status=As specified in the TODO-REPLY  |
          +=====================================================+



2.2  Advanced Calendaring Concepts


   The calendaring and scheduling capability defined by this document is
   based on the exchange of messages between the organizer of a to-do
   and one or more Calendar User Agents (CUA). The message protocol
   emulates a "request" and "reply" form of communications. However,
   there is a class of actions that are non-interactive and are more
   consistent with publishing. These include the publishing of static
   to-dos.

   The message format is designed to be used with either a MIME
   electronic messaging transport, real time protocols, and other
   Internet and non-Internet transports.
   This message-based protocol is based on "request" messages sent from
   an originator and conveyed to one or more recipients. A recipient of
   a "request" message may "reply" to the request, in order to update
   their status and may also return transaction/request status
   information. The protocol also supports the ability for the
   originator of a to-do to change or cancel the original request. The
   elements of the protocol also include the notion of user roles.



Dawson/Hopson/Mansour/Silverberg   8               Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


2.3  Calendar Roles


   Roles are a behavior or set of activities performed by particular
   groups of users or agents at a particular time given the state of the
   application. This specification describes 3 roles that determine a
   range of actions and responsibilities specific to each role. When
   scheduling a to-do with one or more individuals, there are 3 roles:
   OWNER, ORGANIZER and ATTENDEE. The OWNER is generally the originator
   of the to-do request. The OWNER sends the to-do request and receives
   responses from the ATTENDEES. The OWNER is the effective owner of the
   to-do. There are scenarios where the OWNER has an agent or associate
   who acts on the OWNER's behalf, as is the case when your an assistant
   makes assignments for you. In this scenario the ORGANIZER and the
   OWNER are different individuals yet the ORGANIZER is still
   responsible for sending and receiving the requests and managing the
   calendar entities for this to-do.




         Role       Description


         Organi     The organizer is the calendar user that sends
         zer        and manages the to-do --- meaning responses
                     are directed at the organizer. In most cases
                     the organizer is also the owner, but in cases
                     where the owner has the organizer act on it's
                     behalf, the organizer becomes a proxy for the
                     owner. The organizer in this case would place
                     the to-do on the calendar of the owner.


         Owner      The owner generally controls direct
                     manipulation of the to-do. The owner can make
                     unilateral changes to the to-do while the
                     attendees can reply back to the owner. The
                     owner is usually the organizer, but in some
                     cases an agent or associate will act on
                     behalf of the owner and organize the to-do
                     and assignment logistics.


         Attend     Attendees are those recipients who are
         ees        assigned the group to-do. When an attendee
                     responds to the request, the attendee's
                     status property is set to either accept,
                     decline, tentative, or completed




3.   Application Protocol Elements


   Messages are the on-the-wire MIME entities that contain calendaring
   information. The particular type of [ICAL] message is referred to as
   the profile type. Each profile type is identified by a profile
   property specified as part of the Text/Calendar content type. The



Dawson/Hopson/Mansour/Silverberg   9               Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   following describes the various [ICAL] profile types supported in
   this specification.



     Profile Type      Description


        TODO-PUBLISH      Post notification of a to-do. Used
                          primarily as a method of advertising the
                          existence of a to-do. The ATTENDEES
                          property is not included and no
                          interaction is expected.


        TODO-REQUEST      Make a to-do assignment. This is an
                          explicit assignment of a to-do to one or
                          more attendees. To-do requests are also
                          used to update or change an existing to-
                          do description. Clients that cannot
                          handle TODO-REQUEST messages can degrade
                          the to-do to view it as a TODO-PUBLISH.


        TODO-REPLY        Reply to a to-do request. This includes
                          "ACCEPT", "TENTATIVE", "DECLINE" and
                          "COMPLETED".


        TODO-CANCEL       Cancel an existing to-do request. Uses
                          the UID to identify the to-do to be
                          canceled.


        TODO-RESEND       Resend an existing to-do request. Uses
                          the UID to identify the to-do to be
                          resend.




   Each profile type has an associated collection of properties and
   methods. Some properties are required and others are optional. This
   specification is also designed with the notion that some calendaring
   clients will be capable of reading and posting to-dos (where posting
   means to local calendar). Therefore, profiles such as TODO-REQUEST
   will contain an exact superset of the TODO-PUBLISH property set such
   that a client that supported TODO-PUBLISH could still read a TODO-
   REQUEST.

3.1  ITIP Message Conformance


   An implementation conforming to iTIP must enforce the conventions
   described in the sections below. These conventions have been made to
   improve interoperability. As a side benefit, they tend to simplify
   implementation.







Dawson/Hopson/Mansour/Silverberg   10              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


3.1.1     Restrictions on DTSTART and DUE


   The DTSTART property must always be specified. This specifies the
   date/time that the to-do is to first be displayed. The DUE property
   may be specified. This specifies the date/time that the to-do is
   assigned to be completed. If the DUE property is missing, then the
   implicit due date/time for the to-do is to be set to the current
   date, until the to-do is completed. A to-do request containing DUE
   without a DTSTART is not allowed. The DTSTART and the DUE properties
   may have the same value. If the due date/time is known, the DUE
   property should be specified. The DURATION property cannot be
   specified in conjunction with DTSTART.

3.2  Summary of Application Protocol Elements


   This section outlines the complete property set for each profile
   type, indicating the required (designated by the word REQUIRED),
   optional (designed by the words NOT REQUIRED) and excluded
   (designated by the word EXCLUDED) properties.

3.2.1     TODO-PUBLISH


   The TODO-PUBLISH is somewhat unique in this document in that it has
   no response scheduling message associated with it. Instead, it is
   simply a to-do that can be added by a calendar user agent to a
   calendar as a static to-do entry. There is no defined response to the
   originator of a TODO-PUBLISH message. It's expected usage is for
   publication of to-dos such as those that might be published on a
   website or Internet calendar. The TODO-PUBLISH is simply a MIME
   encapsulated file that can be referenced and opened by the
   appropriate handler for a TEXT/CALENDAR MIME content type and EVENT-
   PUBLISH profile type.



     TODO-PUBLISH

     Calendar Properties

        COMMENT
                                   Not Required

        GEO
                                   Not Required

        PRODID
                                   Required

        VERSION
                                   Required, Value must be "2.0".

        PROFILE
                                   Required, "TODO-PUBLISH"

        PROFILE-VERSION
                                   Required, Value must be "1.0".

     Timezone Component Properties

        COMMENT
                                   Not Required




Dawson/Hopson/Mansour/Silverberg   11              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        CREATED
                                   Not Required

        DAYLIGHT
                                   Not Required

        DTSTART
                                   Required

        DTSTART
                                   Not Required

        RDATE
                                   Not Required, Either RDATE or
                                   RRULE may be specified, but not
                                   both.

        RRULE
                                   Not Required, Either RDATE or
                                   RRULE may be specified, but not
                                   both.

        TZNAME
                                   Not Required

        TZOFFSET
                                   Required

        TZTRANS
                                   Not Required

        UID
                                   Required

     Event Component Properties


                                   To-do component is excluded from
                                   this message type.

     To-do Component Properties

        ATTACH
                                   Not Required, "VALUE=URL" only.

        ATTENDEE
                                   Not Required

        CATEGORIES
                                   Not Required

        CLASS
                                   Not Required

        COMMENT
                                   Not Required

        CREATED
                                   Not Required

        COMPLETED
                                   Not Required

        DESCRIPTION
                                   Required, Value may be NULL
                                   text.

        DUE
                                   Not Required

        DURATION
                                   Excluded

        DTEND
                                   Excluded



Dawson/Hopson/Mansour/Silverberg   12              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        DTSTAMP
                                   Required

        DTSTART
                                   Required

        EXDATE
                                   Not Required

        EXRULE
                                   Not Required

        LAST-MODIFIED
                                   Not Required

        LOCATION
                                   Not Required

        PRIORITY
                                   Not Required

        RELATED-TO
                                   Not Required

        REQUEST-STATUS
                                   Excluded

        RDATE
                                   Not Required.

        RRULE
                                   Not Required.

        RESOURCES
                                   Not Required

        RESPONSE-SEQUENCE
                                   Excluded

        SEQUENCE
                                   Required, if not zero.

        STATUS
                                   Not Required.

        SUMMARY
                                   Not Required. May be NULL text.

        TRANSP
                                   Excluded

        URL
                                   Not Required

        UID
                                   Required

     Journal Component Properties


                                   Journal component is excluded
                                   from this message type.

     Alarm Component Properties

        ATTACH
                                   Not Required

        CATEGORIES
                                   Required, If an alarm is
                                   specified

        COMMENT
                                   Not Required

        CREATED
                                   Not Required



Dawson/Hopson/Mansour/Silverberg   13              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        DESCRIPTION
                                   Not Required

        DTSTART
                                   Required, If an alarm is
                                   specified

        DURATION
                                   Required, If an alarm is
                                   specified

        LAST-MODIFIED
                                   Not Required

        RELATED-TO
                                   Not Required

        REPEAT
                                   Required, If an alarm is
                                   specified

        SUMMARY
                                   Not Required

        URL
                                   Not Required

     Freebusy Properties


                                   Freebusy component is excluded
                                   from this message type.

     Non-standard Properties

        X-token
                                   Not Required, but recipient may
                                   choose to ignore those non-
                                   standard properties, specified
                                   as Not Required.




3.2.2     TODO-REQUEST


   The TODO-REQUEST is used to both describe a to-do and assign the to-
   do to one or more attendees. When a TODO-REQUEST is received by a
   user it should be responded to with a TODO-REPLY.



     TODO-REQUEST

     Calendar Properties

        COMMENT
                                     Not Required

        GEO
                                     Not Required

        PRODID
                                     Required

        VERSION
                                     Required, Value must be "2.0".

        PROFILE
                                     Required,"TODO-REQUEST"




Dawson/Hopson/Mansour/Silverberg   14              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        PROFILE-VERSION
                                     Required, Value must be "1.0".

     Timezone Component Properties

        COMMENT
                                     Not Required

        CREATED
                                     Not Required

        DAYLIGHT
                                     Not Required

        DTSTART
                                     Required

        DTEND
                                     Not Required

        RDATE
                                     Not Required, Either RDATE or
                                     RRULE may be specified, but
                                     not both.

        RRULE
                                     Not Required, Either RDATE or
                                     RRULE may be specified, but
                                     not both.

        TZNAME
                                     Not Required

        TZOFFSET
                                     Required

        TZTRANS
                                     Not Required

     Event Component Properties


                                     To-do component is excluded
                                     from this message type.

     To-do Component Properties

        ATTACH
                                     Not Required, "VALUE=URL"
                                     only.

        ATTENDEE
                                     Required, Value is an RFC822
                                     mailbox address for C&S
                                     capability. STATUS parameter
                                     is either absent or has value
                                     "NEEDS ACTION".

        CATEGORIES
                                     Not Required

        CLASS
                                     Not Required

        COMMENT
                                     Not Required

        CREATED
                                     Not Required

        COMPLETED
                                     Not Required




Dawson/Hopson/Mansour/Silverberg   15              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        DESCRIPTION
                                     Required, Value may be NULL
                                     text.

        DUE
                                     Not Required

        DURATION
                                     Excluded

        DTEND
                                     Excluded

        DTSTAMP
                                     Required

        DTSTART
                                     Required

        EXDATE
                                     Not Required.

        EXRULE
                                     Not Required.

        LAST-MODIFIED
                                     Not Required

        LOCATION
                                     Not Required

        PRIORITY
                                     Not Required

        RELATED-TO
                                     Not Required

        REQUEST-REPLY
                                     Excluded

        RDATE
                                     Not Required.

        RRULE
                                     Not Required.

        RESOURCES
                                     Not Required

        RESPONSE-SEQUENCE
                                     Excluded

        SEQUENCE
                                     Required, If not zero.

        STATUS
                                     Not Required, Value only one
                                     of TENTATIVE | ACCEPTED |
                                     CANCELLED. This property is
                                     used by the originator to
                                     indicate the consensus for the
                                     to-do, not a status on any of
                                     the attendees.

        SUMMARY
                                     Not Required, May be NULL
                                     text.

        TRANSP
                                     Excluded

        URL
                                     Not Required



Dawson/Hopson/Mansour/Silverberg   16              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        UID
                                     Required, Must be maintained
                                     by the recipients.

     Journal Component Properties


                                     Journal component is excluded
                                     from this message type.

     Alarm Component Properties

        ATTACH
                                     Not Required

        CATEGORIES
                                     Required, If an alarm is
                                     specified

        COMMENT
                                     Not Required

        CREATED
                                     Not Required

        DESCRIPTION
                                     Not Required

        DTSTART
                                     Required, If an alarm is
                                     specified

        DURATION
                                     Required, If an alarm is
                                     specified

        LAST-MODIFIED
                                     Not Required

        RELATED-TO
                                     Not Required

        REPEAT
                                     Required, If an alarm is
                                     specified

        SUMMARY
                                     Not Required

        URL
                                     Not Required

     Freebusy Properties


                                     Freebusy component is excluded
                                     from this message type.

     Non-standard Properties

        X-token
                                     Not Required, but recipient
                                     may choose to ignore those
                                     non-standard properties,
                                     specified as Not Required.









Dawson/Hopson/Mansour/Silverberg   17              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


3.2.3     TODO-REPLY


   The TODO-REPLY is used to by the attendees to reply to the originator
   of the to-do request with their status. The attendees can indicate
   their status is a TENTATIVE acceptance, that they have ACCEPTED the
   assignment, that they DECLINED the assignment or that they have
   COMPLETED the assignment. Once an attendee has replied to the
   request, they can subsequently reply with a different value.



     TODO-REPLY

     Calendar Properties

        COMMENT
                                     Not Required

        GEO
                                     Not Required

        PRODID
                                     Required

        VERSION
                                     Required, Value must be "2.0".

        PROFILE
                                     Required,"TODO-REPLY"

        PROFILE-VERSION
                                     Required, Value must be "1.0".

     Timezone Component Properties


                                     Timezone component is excluded
                                     from this message type.

     Event Component Properties


                                     Event component is excluded
                                     from this message type.

     To-do Component Properties

        ATTACH
                                     Excluded

        ATTENDEE
                                     Required, Value is an RFC822
                                     mailbox address for C&S
                                     capability. Must be the
                                     address of the recipient
                                     replying.

        CATEGORIES
                                     Excluded

        CLASS
                                     Excluded

        COMMENT
                                     Text value. Provides a comment
                                     from the recipient to the
                                     originator about the reply.
                                     For example, "I am too busy to
                                     accept this assignment."




Dawson/Hopson/Mansour/Silverberg   18              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        CREATED
                                     Excluded

        COMPLETED
                                     Not Required

        DESCRIPTION
                                     Excluded

        DUE
                                     Excluded

        DURATION
                                     Excluded

        DTEND
                                     Excluded

        DTSTAMP
                                     Required

        DTSTART
                                     Excluded

        EXDATE
                                     Not Required. Specifies the
                                     dates that are exceptions to
                                     the status update.

        EXRULE
                                     Not Required. Specifies the
                                     rule that defines the
                                     exceptions to the status
                                     update.

        LAST-MODIFIED
                                     Excluded

        LOCATION
                                     Excluded

        PRIORITY
                                     Excluded

        RELATED-TO
                                     Excluded

        REQUEST-STATUS
                                     Not Required. Any of the
                                     values defined in the table
                                     below.

        RDATE
                                     Excluded

        RRULE
                                     Excluded

        RESOURCES
                                     Excluded

        RESPONSE-SEQUENCE
                                     Required, If not zero.

        SEQUENCE
                                     Required, If not zero

        STATUS
                                     Excluded. Status for attendee
                                     must be specified in STATUS
                                     parameter of ATTENDEE
                                     property.



Dawson/Hopson/Mansour/Silverberg   19              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        SUMMARY
                                     Excluded

        TRANSP
                                     Excluded

        URL
                                     Excluded

        UID
                                     Required, Must be the UID of
                                     the EVENT-REQUEST associate
                                     with the reply.

     Journal Component Properties


                                     Journal component is excluded
                                     from this message type.

     Alarm Component Properties


                                     Alarm component is excluded
                                     from this message type.

     Freebusy Properties


                                     Freebusy component is excluded
                                     from this message type.

     Non-Standard Properties

        X-token
                                     Not Required, but recipient
                                     may choose to ignore those
                                     non-standard properties,
                                     specified as Not Required.



3.2.4     TODO-CANCEL


   The TODO-CANCEL is used to by the originator of the to-do request to
   convey a cancellation notice of the to-do to the attendees. The
   message is only sent by the to-do OWNER or ORGANIZER to the
   recipients of the original to-do request.



     TODO-CANCEL

        Calendar Properties

        COMMENT
                                     Not Required

        GEO
                                     Not Required

        PRODID
                                     Required

        VERSION
                                     Required, Value must be "2.0".

        PROFILE
                                     Required,"TODO-CANCEL"

        PROFILE-VERSION
                                     Required, Value must be "1.0".



Dawson/Hopson/Mansour/Silverberg   20              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



     Timezone Component Properties


                                     Timezone component is excluded
                                     from this message type.

     Event Component Properties


                                     Event component is excluded
                                     from this message type.

     To-do Component Properties

        ATTACH
                                     Excluded

        ATTENDEE
                                     Excluded

        CATEGORIES
                                     Excluded

        CLASS
                                     Excluded

        CREATED
                                     Excluded

        COMMENT
                                     Not Required, Text value.
                                     Provides a comment from the
                                     originator to the attendees
                                     concerning the cancellation
                                     notice.

        COMPLETED
                                     Excluded

        DESCRIPTION
                                     Excluded

        DUE
                                     Excluded

        DURATION
                                     Excluded

        DTEND
                                     Excluded

        DTSTAMP
                                     Excluded

        DTSTART
                                     Excluded

        EXDATE
                                     Excluded

        EXRULE
                                     Excluded

        LAST-MODIFIED
                                     Excluded

        LOCATION
                                     Excluded

        PRIORITY
                                     Excluded

        RELATED-TO
                                     Excluded




Dawson/Hopson/Mansour/Silverberg   21              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        REQUEST-STATUS
                                     Excluded

        RDATE
                                     Excluded

        RRULE
                                     Excluded

        RESOURCES
                                     Excluded

        RESPONSE-SEQUENCE
                                     Excluded

        SEQUENCE
                                     Required, if not zero. Is not
                                     incremented by this action.

        STATUS
                                     Not Required, If present value
                                     must be "CANCELLED".

        SUMMARY
                                     Excluded

        TRANSP
                                     Excluded

        URL
                                     Not Required

        UID
                                     Required, Must be the UID of
                                     the original EVENT-REQUEST
                                     associated with the
                                     cancellation notice.

     Journal Component Properties


                                     Journal component is excluded
                                     from this message type.

     Alarm Properties


                                     Alarm component is excluded
                                     from this message type.

     Freebusy Protperties


                                     Freebusy component is excluded
                                     from this message type.

     Non-standard Properties

        X-token
                                     Not Required, But recipient
                                     may choose to ignore those
                                     non-standard properties,
                                     specified as optional.



3.2.5     Rescheduling or Changing a To-do


   When an owner/organizer desires to reschedule or change some detail
   of one of their existing to-do requests, they effect this change by
   conveying a new to-do request with the same UID and an incremented



Dawson/Hopson/Mansour/Silverberg   22              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   sequence number. The receiving client must correlate the request to
   their existing to-dos and check the sequence number in order to
   realize that the request is actually a replacement for the existing
   to-do. Individual "A" sends a to-do request to "B" and "C". "B"
   accepts the to-do and "C" declines and includes text in the comments
   property proposing a more appropriate due date. "A" sends "B" and "C"
   another to-do request using the same UID and a sequence number one
   greater than the original request. "B" should infer that the to-do
   request message is actually a replacement for the existing to-do.

   Replacing a to-do request is predicated on using the same UID,
   incrementing the sequence number and replacing the changed calendar
   properties.



     TODO-REQUEST (replacing an existing to-do description)

     Calendar Properties

        COMMENT
                                     Not Required

        GEO
                                     Not Required

        PRODID
                                     Required

        VERSION
                                     Required, Value must be "2.0".

        PROFILE
                                     Required,"TODO-REQUEST"

        PROFILE-VERSION
                                     Required, Value must be "1.0".

     Timezone Component Properties

        COMMENT
                                     Not Required

        CREATED
                                     Not Required

        DAYLIGHT
                                     Not Required

        DTSTART
                                     Required

        DTEND
                                     Not Required

        RDATE
                                     Not Required, Either RDATE or
                                     RRULE may be specified, but
                                     not both.

        RRULE
                                     Not Required, Either RDATE or
                                     RRULE may be specified, but
                                     not both.

        TZNAME
                                     Not Required

        TZOFFSET
                                     Required



Dawson/Hopson/Mansour/Silverberg   23              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        TZTRANS
                                     Not Required

     Event Component Properties


                                     Event component is excluded
                                     from this message type.

     To-do Component Properties

        ATTACH
                                     Not Required, "VALUE=URL"
                                     only.

        ATTENDEE
                                     Required, Value is an RFC822
                                     mailbox address for C&S
                                     capability. STATUS parameter
                                     is either absent or has value
                                     "NEEDS ACTION".

        CATEGORIES
                                     Not Required

        CLASS
                                     Not Required

        COMMENT
                                     Not Required

        CREATED
                                     Not Required

        COMPLETED
                                     Excluded

        DESCRIPTION
                                     Required, Value may be NULL
                                     text.

        DUE
                                     Not Required, must be after or
                                     the same as the DTSTART
                                     date/time.

        DURATION
                                     Excluded

        DTEND
                                     Excluded

        DTSTAMP
                                     Required

        DTSTART
                                     Required

        EXDATE
                                     Not Required.

        EXRULE
                                     Not Required.

        LAST-MODIFIED
                                     Not Required

        LOCATION
                                     Not Required

        PRIORITY
                                     Not Required




Dawson/Hopson/Mansour/Silverberg   24              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        RELATED-TO
                                     Not Required

        REQUEST-STATUS
                                     Excluded

        RDATE
                                     Not Required

        RRULE
                                     Not Required

        RESOURCES
                                     Not Required

        RESPONSE-SEQUENCE
                                     Excluded

        SEQUENCE
                                     Must be greater than 0 and
                                     should be monotomically
                                     incremented for each request

        STATUS
                                     Not Required, Value only one
                                     of TENTATIVE | CONFIRMED |
                                     CANCELLED. This property is
                                     used by the originator to
                                     indicate the consensus for the
                                     to-do, not a status on any of
                                     the attendees.

        SUMMARY
                                     Not Required, May be NULL
                                     text.

        TRANSP
                                     Excluded

        URL
                                     Not Required

        UID
                                     Required, Must match the
                                     original meeting request which
                                     this request replaces

     Journal Component Properties


                                     Journal component is excluded
                                     from this message type.

     Alarm Component Properties

        ATTACH
                                     Not Required

        CATEGORIES
                                     Required, If an alarm is
                                     specified

        CREATED
                                     Not Required

        DESCRIPTION
                                     Not Required

        DTSTART
                                     Required, If an alarm is
                                     specified



Dawson/Hopson/Mansour/Silverberg   25              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        DURATION
                                     Required, If an alarm is
                                     specified

        LAST-MODIFIED
                                     Not Required

        RELATED-TO
                                     Not Required

        REPEAT
                                     Required, If an alarm is
                                     specified

        SUMMARY
                                     Not Required

        URL
                                     Not Required

     Freebusy Component Properties


                                     Freebusy component is excluded
                                     from this message type.

     Non-standard Properties

        X-token
                                     Not Required, but recipient
                                     may choose to ignore those
                                     non-standard properties,
                                     specified as Not Required.




3.2.6     TODO-RESEND


   The TODO-RESEND is used by attendees to request the latest version of
   a TODO-REQUEST. By issuing an TODO-RESEND, with the appropriate UID
   and optionally a RECURRENCE-ID, the organizer's CUA should respond
   with the latest version of the to-do. This message type is intended
   to be machine processed.



     TODO-RESEND

        Calendar Properties

        COMMENT
                                     Not Required

        GEO
                                     Not Required

        PRODID
                                     Required

        VERSION
                                     Required, Value must be "2.0".

        PROFILE
                                     Required,"TODO-RESEND"

        PROFILE-VERSION
                                     Required, Value must be "1.0".

     Timezone Component Properties




Dawson/Hopson/Mansour/Silverberg   26              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997




                                     Timezone component is excluded
                                     from this message type.

     Event Component Properties


                                     Event component is excluded
                                     from this message type.

     To-do Component Properties

        ATTACH
                                     Excluded

        ATTENDEE
                                     Excluded

        CATEGORIES
                                     Excluded

        CLASS
                                     Excluded

        CREATED
                                     Excluded

        COMMENT
                                     Not Required, Text value.
                                     Provides a comment from the
                                     attendee to the organizer
                                     concerning the resend request.

        COMPLETED
                                     Excluded

        DESCRIPTION
                                     Excluded

        DUE
                                     Excluded

        DURATION
                                     Excluded

        DTEND
                                     Excluded

        DTSTAMP
                                     Required

        DTSTART
                                     Excluded

        EXDATE
                                     Excluded

        EXRULE
                                     Excluded

        LAST-MODIFIED
                                     Excluded

        LOCATION
                                     Excluded

        PRIORITY
                                     Excluded

        RELATED-TO
                                     Excluded

        REQUEST-STATUS
                                     Excluded




Dawson/Hopson/Mansour/Silverberg   27              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



        RDATE
                                     Excluded

        RRULE
                                     Excluded

        RECURRENCE-ID
                                     Not Required. If the attendee
                                     wishes to receive an updated
                                     instance of a recurring to-do,
                                     then the RECURRENCE-ID can be
                                     included and only the specific
                                     instance will be returned.

        RESOURCES
                                     Excluded

        RESPONSE-SEQUENCE
                                     Excluded

        SEQUENCE
                                     Required, if not zero. Is not
                                     incremented by this action.

        STATUS
                                     Excluded

        SUMMARY
                                     Excluded

        TRANSP
                                     Excluded

        URL
                                     Excluded

        UID
                                     Required, Must be the UID of
                                     the original EVENT-REQUEST
                                     associated with the
                                     cancellation notice.

     Journal Component Properties


                                     Journal component is excluded
                                     from this message type.

     Alarm Properties


                                     Alarm component is excluded
                                     from this message type.

     Freebusy Protperties


                                     Freebusy component is excluded
                                     from this message type.

     Non-standard Properties

        X-token
                                     Not Required, But recipient
                                     may choose to ignore those
                                     non-standard properties,
                                     specified as optional.






Dawson/Hopson/Mansour/Silverberg   28              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


3.3  Request Status Codes


   The following is a list of possible return status codes values:



    Short      Longer Return Status        Offending Data
    Return     Description
    Status
    Code

       200
                  Success.                    None.

       201
                  Success, but fallback       Property name and
                  taken on one or more        value may be
                  property values.            specified.

       202
                  Success, invalid            Property name may be
                  property ignored.           specified.

       203
                  Success, invalid            Property parameter
                  property parameter          name and value may be
                  ignored.                    specified.

       204
                  Success, unknown non-       Non-standard property
                  standard property           name may be
                  ignored.                    specified.

       205
                  Success, unknown non-       Property and non-
                  standard property value     standard value may be
                  ignored.                    specified.

       206
                  Success, invalid            Calendar component
                  calendar component          sentinel (e.g.,
                  ignored.                    "BEGIN:ALARM") may be
                                               specified.

       207
                  Success, request            Original and
                  forwarded to calendar       forwarded RFC822
                  user.                       addresses may be
                                               specified.

       208
                  Success, repeating event    RRULE or RDATE
                  ignored. Scheduled as a     property name and
                  single event.               value may be
                                               specified.

       209
                  Success, truncated end      DTEND property value
                  date/time to date           may be specified.
                  boundary.

       210
                  Success, repeating to-do    RRULE or RDATE
                  ignored. Scheduled as a     property name and



Dawson/Hopson/Mansour/Silverberg   29              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



                  single to-do.               value may be
                                               specified.

       300
                  Invalid property name.      Property name may be
                                               specified.

       301
                  Invalid property value.     Property name and
                                               value may be
                                               specified.

       302
                  Invalid property            Property parameter
                  parameter.                  name and value may be
                                               specified.

       303
                  Invalid property            Property parameter
                  parameter value.            name and value may be
                                               specified.

       304
                  Invalid calendar            Calendar component
                  component sequence.         sentinel may be
                                               specified (e.g.,
                                               BEGIN:TIMEZONE).

       305
                  Invalid date or time.       Date/time value(s)
                                               may be specified.

       306
                  Invalid rule.               Rule value may be
                                               specified.

       307
                  Invalid calendar user.      Attendee property
                                               value may be
                                               specified.

       308
                  No authority.               PROFILE and ATTENDEE
                                               property values may
                                               be specified.

       309
                  Unsupported version.        VERSION property name
                                               and value may be
                                               specified.

       310
                  Request entity too          None.
                  large.

       400
                  Event conflict.             DTSTART and DTEND
                  Date/time is busy.          property name and
                                               values may be
                                               specified.

       500
                  Request not supported.      Profile property
                                               value may be
                                               specified.




Dawson/Hopson/Mansour/Silverberg   30              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



       501
                  Service unavailable.        ATTENDEE property
                                               value may be
                                               specified.

       502
                  Invalid calendar            ATTENDEE property
                  service.                    value may be
                                               specified.

       503
                  No scheduling support       ATTENDEE property
                  for user.                   value may be
                                               specified.




4.   Examples


4.1  Published To-Dos


   In the calendaring and scheduling context, publication refers to the
   one way transfer of to-do information. Consumers of published to-dos
   simply incorporate the to-do into a calendar. No reply is expected.
   Individual "A" publishes a to-do. Individual "B" reads the to-do and
   incorporates it into their calendar. To-dos can be published in
   several ways including: embedding the to-do as an object in a web
   page, e-mailing the to-do to a distribution list, and posting the to-
   do to a newsgroup.

   The table below illustrates the sequence of to-dos between the
   publisher and the consumers of a published to-do.



         Action                Organizer                Attendee


         Publish a to-do       "A" sends or posts a
                                TODO-PUBLISH message


         "B" reads the to-
         do publication


         Publish an updated    "A" sends or posts a
         to-do                 TODO-PUBLISH message


         "B" reads the
         updated to-do
         publication


         Cancel a published    "A" sends or posts a
         to-do                 toDO-CANCEL message


         "B" reads the
         canceled to-do



Dawson/Hopson/Mansour/Silverberg   31              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



         publication


4.1.1     A Minimal Published To-Do


   The iCalendar Object below describes a single to-do is due on October
   1, 1997 at 20:00 UTC. This to-do contains the minimum set of
   properties for an iTIP to-do component.

   BEGIN:VCALENDAR
   PROFILE:TODO-PUBLISH
   PROFILE-VERSION:1.0
   PRODID:-//ACME/DesktopCalendar//EN
   VERSION:2.0
   BEGIN:VTODO
   DUE:19971001T200000Z
   SUMMARY:Book Report on Fiction Novel
   UID:0981234-1234234-2300
   DTSTAMP:19970717T200000Z
   END:VTODO
   END:VCALENDAR

4.1.2     Changing A Published To-Do


   The iCalendar Object below describes an update to the to-do described
   in 4.1.1, the due date has been changed, a start time has been added,
   and the sequence number has been adjusted.

   BEGIN:VCALENDAR
   PROFILE:TODO-PUBLISH
   PROFILE-VERSION:1.0
   VERSION:2.0
   PRODID:-//ACME/DesktopCalendar//EN
   BEGIN:VTODO
   DTSTART:19970901T210000Z
   DUE:19971005T200000Z
   SEQUENCE:2
   UID:0981234-1234234-2300
   SUMMARY:Book Report on Fiction Novel
   DTSTAMP:19970717T200000Z
   STATUS:NEEDS-ACTION
   END:VTODO
   END:VCALENDAR

   To identify the to-do the client uses the UID. The SEQUENCE property
   indicates that this is the second change to the to-do. To-dos with
   sequence numbers 0 and 1 are superseded by this to-do.

   The SEQUENCE property provides a reliable way to distinguish
   different versions of the same to-do. Each time a to-do is published,
   its sequence number is incremented. If a client receives a to-do with
   a sequence number 5 and finds it has the same to-do with sequence
   number 2, the to-do should be updated. However, if the client




Dawson/Hopson/Mansour/Silverberg   32              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   received a to-do with sequence number 2 and finds it already has
   sequence number 5 of the same to-do, the to-do should not be updated.

4.1.3     Canceling A Published To-Do


   The iCalendar Object below cancels the to-do described in 4.1.1. This
   cancels the to-do with SEQUENCE numbers 0, 1, and 2.

   BEGIN:VCALENDAR
   PROFILE:TODO-CANCEL
   PROFILE-VERSION:1.0
   VERSION:2.0
   PRODID:-//ACME/DesktopCalendar//EN
   BEGIN:VTODO
   COMMENT:As discussed in class, you are all off the hook!
   SEQUENCE:2
   UID:0981234-1234234-2300
   STATUS:CANCELLED
   DTSTAMP:19970717T200000Z
   END:VTODO
   END:VCALENDAR


4.1.4     A Rich Published To-Do


   This example describes the same to-do as in 4.1.1, but in much
   greater detail.

   BEGIN:VCALENDAR

   BEGIN:VTIMEZONE
   DAYLIGHT:TRUE
   DTSTART:19970406T000000
   RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY
   TZNAME:CDT
   TZOFFSET:-0500
   TTRANS:020000
   END:VTIMEZONE

   BEGIN:VTIMEZONE
   DAYLIGHT:FALSE
   DTSTART:19970101T000000
   RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY
   TZNAME:CST
   TZOFFSET:-0600
   TTRANS:020000
   END:VTIMEZONE

   PRODID:-//ACME/DesktopCalendar//EN
   PROFILE:TODO-PUBLISH
   PROFILE-VERSION:1.0
   CALSCALE:GREGORIAN
   SOURCE:http://www.acmeu.edu/courses/eng-lit-101/Fall97-to-dos.or4



Dawson/Hopson/Mansour/Silverberg   33              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   NAME:English Literature 101 Course Calendar
   VERSION:2.0

   BEGIN:VTODO
   ATTACH:http://www.midwaystadium.com/courses/eng-lit-101/
   CATEGORIES:EDUCATION;COURSE-ASSIGNMENT
   CLASS:PRIVATE
   CREATED:19970415T194319Z
   DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:Book Report =
   1=0A=0D=
    Fiction=0A=0D=
    Dr. Ling must approve the book you choose=0A=0D=
    book report structure can be found on:=
    http://www.acmeu.com/courses/eng-lit-101/bookreports.html
   DTSTART:19970901T210000Z
   DUE:19971005T200000Z
   COMPLETED:19971005T150000Z
   DTSTAMP:19970717T200000Z
   SEQUENCE:2
   UID:0981234-1234234-2300
   LAST-MODIFIED:19971005T132421Z
   RESOURCES:COMPUTER,PRINTER
   LOCATION;VALUE=URL:http://www.acmeu.com/campusmaps/haaghall.html
   PRIORITY:2
   SEQUENCE:3
   SUMMARY:Book Report on Fiction Novel
   UID:0981234-1234234-2300
   STATUS:NEEDS-ACTION
   RELATED-TO:0981234-1234234-1400

   BEGIN:VALARM
   DTSTART:19970910T190000Z
   REPEAT:2
   DURATION:PT2H
   CATEGORIES:DISPLAY,AUDIO
   DESCRIPTION;CHARSET=US-ASCII;ENCODING=QUOTED-PRINTABLE:Book report
   rough draft
   END:VALARM

   BEGIN:VALARM
   DTSTART:19970930T153000
   CATEGORIES:DISPLAY,AUDIO
   DESCRIPTION:You should be reviewing your final book report draft.
   END:VALARM

   END:VTODO
   END:VCALENDAR


   The CLASS property is specified, though it is not really needed here.
   Since this is a published to-do, a program that displays it need not
   apply any content filtering based on the CLASS attribute. If this to-
   do is copied into a users calendar, the CLASS would be included as



Dawson/Hopson/Mansour/Silverberg   34              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   part of the copy. The handling of the CLASS tag at that point is
   implementation specific.

   The RELATED-TO field contains the UID of a related calendar to-do or
   event. The handling of this property is application dependent.

   VTIMEZONE components are discussed in detail in iTIP Part 1.

   The sequence number 3 indicates that this to-do supersedes versions
   0, 1, and 2.

4.2  Group To-Do Examples


   Group to-dos are distinguished from published to-dos in that there is
   interaction between the attendees with respect to the to-do.
   Individual "A" creates a group task in which individuals "A", "B",
   "C" and "D" will participate. Individual "B" confirms acceptance of
   the task. Individual "C" declines the task. Individual "D"
   tentatively accepts the task. The following table illustrates the
   sequence of messages that would be exchanged between these
   individuals. The table below illustrates the message flow.




         Action          Organizer           Attendee


         Initiate a      "A" sends TODO-
         to-do           REQUEST message
         request         to "B", "C", and
                         "D"


         Accept the                          "B" sends TODO-
         to-do                               REPLY message to
         request                             "A" with its
                                              ATTENDEE/STATUS
                                              property parameter
                                              set to "ACCEPTED"


         Decline the                         "C" sends TODO-
         to-do                               REPLY message to
         request                             "A" with its
                                              ATTENDEE/STATUS
                                              property parameter
                                              set to "DECLINED"


         Tentatively                         "D" sends TODO-
         accept the                          REPLY message to
         to-do                               "A" with its
         request                             ATTENEE/STATUS
                                              property parameter
                                              set to "TENTATIVE"


         Confirm to-     "A" sends TODO-



Dawson/Hopson/Mansour/Silverberg   35              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



         do status       REQUEST message
         with            to "B" and "C"
         attendees       with current
                         information for
                         to-do. SEQUENCE
                         property is "1".




4.2.1     A To-Do Request


   A sample to-do request that "A" sends to "B", "C", and "D".

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   PROFILE:TO-DO-REQUEST
   PROFILE-VERSION:1.0
   VERSION:2.0
   BEGIN:VTODO
   ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:D@acme.com
   DTSTART:19970701T100000-0700
   DUE:19970722T100000-0700
   SUMMARY:Create the requirements document
   UID:www.acme.com-873970198738777-00
   SEQUENCE:0
   DTSTAMP:19970717T200000Z
   STATUS:NEEDS-ACTION
   END:VTODO
   END:VCALENDAR

   Note that the conference room does not have a valid e-mail address.

4.2.2     A To-Do Reply


   Attendee "B" accepts the meeting.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   PROFILE:TODO-REPLY
   PROFILE-VERSION:1.0
   VERSION:2.0
   BEGIN:VTODO
   ATTENDEE;STATUS=ACCEPTED:B@acme.com
   UID:www.acme.com-873970198738777-00
   COMMENT:I'll send you my input by e-mail
   SEQUENCE:0
   RESPONSE-SEQUENCE:0
   DTSTAMP:19970717T200000Z
   REQUEST-STATUS:0;Success
   END:VTODO



Dawson/Hopson/Mansour/Silverberg   36              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   END:VCALENDAR


   "B" could have declined the meeting or indicated tentative acceptance
   by setting the ATTENDEE;STATUS parameter to DECLINED or TENTATIVE,
   respectively.


4.2.3     Update A To-do


   The to-do is moved to a different time. The combination of the UID
   (which remains the same) and the SEQUENCE (bumped to 1) properties
   indicate the update.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   PROFILE:TODO-REQUEST
   PROFILE-VERSION:1.0
   VERSION:2.0
   BEGIN:VTO-DO
   ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:A@acme.com
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:B@acme.com
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:C@acme.com
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:D@acme.com
   DTSTART:19970701T110000-0700
   DUE:19970722T100000-0700
   COMPLETED:19970720T090000-0700
   DTSTAMP:19970717T200000Z
   STATUS:COMPLETED
   SUMMARY:Create the requirements document
   UID:www.acme.com-873970198738777
   SEQUENCE:1
   END:VTODO
   END:VCALENDAR

4.3  Recurring To-do and Time Zone Examples


4.3.1     A Recurring To-do That Spans Timezones


   This to-do describes a weekly status report. The attendees are each
   in a different timezone.

   BEGIN:VCALENDAR

   BEGIN:VTIMEZONE
   DAYLIGHT:TRUE
   DTSTART:19970406T000000
   RRULE:BYDAY=1SU;BYMONTH=4;FREQ=YEARLY
   TZNAME:PDT
   TZOFFSET:-0700
   TTRANS:020000
   END:VTIMEZONE




Dawson/Hopson/Mansour/Silverberg   37              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997



   BEGIN:VTIMEZONE
   DAYLIGHT:FALSE
   DTSTART:19970126T000000
   RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=YEARLY
   TZNAME:PST
   TZOFFSET:-0800
   TTRANS:020000
   END:VTIMEZONE

   PRODID:-//ACME/DesktopCalendar//EN
   PROFILE:TODO-REQUEST
   VERSION:2.0

   BEGIN:VTODO
   ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:sman@mcom.com
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:gb@mcom.fr
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:kimiko@mcom.jp
   DTSTART:19970701T140000
   DUE:19970701T150000
   RRULE:INTERVAL=20;WKST=SU;BYDAY=TU;FREQ=WEEKLY
   RDATE:19970910T140000
   EXDATE:19970909T140000
   EXDATE:19971028T150000
   SUMMARY:Weekly Status Report
   UID:www.acme.com-873970198738777
   SEQUENCE:0
   DTSTAMP:19970601T200000Z
   STATUS:NEEDS-ACTION
   END:VTODO

   END:VCALENDAR

   Timezone components should appear in an iCalendar Object containing
   recurring to-dos. This is especially important if a recurring to-do
   has attendees in different timezones. There can be multiple VTIMEZONE
   components in an iCalendar Object. However, they must be used to
   define the same timezone. That is, there cannot be VTIMEZONE
   components describing both PST/PDT and EST/EDT at the component level
   in the same iCalendar Object.

   The first two components of this iCalendar Object are the timezone
   components. The DTStart date coincides with the first instance of the
   RRULE property.

   The recurring to-do is defined in a particular timezone, presumably
   that of the creator. The client for each attendee has the
   responsibility of determining the recurrence time in the attendee's
   timezone.

   The first instance of the to-do starts on Tuesday, July 1, 1997 at
   2:00pm. Since no timezone is specified in the DTSTART property, the
   timezone component of PDT applies to the start and end times.
   Attendee gb@mcom.fr is in France where the local time on this date is


Dawson/Hopson/Mansour/Silverberg   38              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   7 hours later than PDT or 21:00. Attendee kimiko@mcom.jp is in Japan
   where local time is 9 hours ahead of than UTC or Wednesday, July 2 at
   07:00. The to-do repeats weekly on Tuesdays (in PST/PDT). The RRULE
   results in 20 instances. The last instance falls on Tuesday, November
   11, 1997 2:00pm PST. The RDATE adds another instance: WED, 10-SEP-
   1997 21:00 GMT.

   There are two exceptions to this recurring appointment. The first one
   is:

     TUE, 09-SEP-1997 21:00 GMT
     TUE, 09-SEP-1997 14:00 PDT
     WED, 10-SEP-1997 07:00 JDT

   and the second is:

     TUE, 28-OCT-1997 22:00 GMT
     TUE, 28-OCT-1997 14:00 PST
     WED, 29-OCT-1997 07:00 JST

4.3.2     Creating  an Exception to a Recurring To-Do


   The following example illustrates a scenario where a to-do organizer
   changes an instance of an existing recurring to-do. In this case the
   organizer is changing the start and end time.

   Original Request:

   BEGIN:VCALENDAR
   PROFILE:TODO-REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VTODO
   CREATED:19970526T083000
   UID:guid-1.host1.com-001
   SEQUENCE:0
   RRULE:BYMONTHDAY=1;FREQ=MONTHLY
   ATTENDEE;ROLE=ORGANIZER;STATUS=ACCEPTED:Sman@netscape.com
   ATTENDEE;RSVP=YES:fdawson@earthlink.net
   ATTENDEE;RSVP=YES:Deriks@Microsoft.com
   ATTENDEE;RSVP=YES:Alecd@Microsoft.com
   DESCRIPTION:IETF-C&S Conference Call
   CLASS:PUBLIC
   SUMMARY:Merge document updates
   DTSTART:19970601T210000Z
   DUE:19970601T220000Z
   LOCATION:Conference Call
   DTSTAMP:19970601T200000Z
   STATUS:NEEDS-ACTION
   END:VTODO
   END:VCALENDAR





Dawson/Hopson/Mansour/Silverberg   39              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   To-do Request to change a time and create an exception:

   BEGIN:VCALENDAR
   PROFILE:TODO-REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VTODO
   UID:guid-1.host1.com-001
   SEQUENCE:1
   RECURRENCE-ID:19970701T210000Z
   DTSTART:19970703T210000Z
   DUE:19970703T220000Z
   DTSTAMP:19970701T200000Z
   END:VTODO
   END:VCALENDAR


4.3.3     Modify Exception


   In this example the organizer has already created an exception and
   now wishes to make additional property modification. The organizer
   must use both the RECURRENCE-ID and UID to reference the exception.

   BEGIN:VCALENDAR
   PROFILE:TODO-REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VTODO
   UID:guid-1.host1.com-001
   SEQUENCE:2
   RECURRENCE-ID:19970701T210000Z
   ATTENDEE;EXPECT=REQUEST:Sman@netscape.com
   ATTENDEE;EXPECT=REQUEST:fdawson@earthlink.net
   ATTENDEE;EXPECT=REQUEST:Deriks@Microsoft.com
   ATTENDEE;EXPECT=REQUEST:Alecd@Microsoft.com
   ATTENDEE;EXPECT=REQUEST:RHopson@dev.davinci.com
   DESCRIPTION:Emergency Meeting
   CLASS:Private
   DTSTAMP:19970701T200000Z
   STATUS:NEEDS-ACTION
   END:VTODO
   END:VCALENDAR

This example changes the specific instance properties without changing
the recurring meeting parent.


4.3.4     Cancel an Exception


   In the following example, the organizer has created an exception as
   in 4.3.2 and now wishes to cancel it. In this case a TODO-CANCEL is
   sent with the specific RECURRENCE-ID and UID of the exception.




Dawson/Hopson/Mansour/Silverberg   40              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   BEGIN:VCALENDAR
   PROFILE:TODO-CANCEL
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VTODO
   UID:guid-1.host1.com-001
   RECURRENCE-ID:19970701T210000Z
   SEQUENCE:2
   DTSTAMP:19970701T200000Z
   STATUS:CANCELLED
   END:VTODO
   END:VCALENDAR

4.3.5     Cancel Recurring To-Do


   In this example the organizer wishes to cancel the entire recurring
   to-do and any child exceptions.

   BEGIN:VCALENDAR
   PROFILE:TODO-CANCEL
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VTODO
   UID:guid-1.host1.com-001
   SEQUENCE:2
   DTSTAMP:19970701T200000Z
   STATUS:CANCELLED
   END:VTODO
   END:VCALENDAR


4.3.6     Decline A Previously Accepted Exception


   In this example a recipient has accepted a TODO-REQUEST which is
   actually an exception. The recipient now wishes to decline after
   previously accepting

   Recipient initially accepts to-do request:

   BEGIN:VCALENDAR
   PROFILE:TODO-REPLY
   VERSION:2.0
   PRODID:-//ABC Corporation//NONSGML My Product//EN
   BEGIN:VTODO
   SEQUENCE:1
   RESPONSE-SEQUENCE:1
   UID:guid-1.host1.com-001
   RECURRENCE-ID:19970701T210000Z
   ATTENDEE;STATUS=CONFIRMED:Deriks@Microsoft.com
   REQUEST-STATUS:0;Success
   DTSTAMP:19970701T200000Z
   RESPONSE-SEQUENCE:0
   END:VTODO



Dawson/Hopson/Mansour/Silverberg   41              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   END:VCALENDAR

   Recipient later wishes to decline the request to a recurring
   exception:

   BEGIN:VCALENDAR
   PROFILE:TODO-REPLY
   VERSION:2.0
   PRODID:-//ABC Corporation//NONSGML My Product//EN
   BEGIN:VTODO
   SEQUENCE:0
   RESPONSE-SEQUENCE:1
   UID:guid-1.host1.com
   RECURRENCE-ID:19970701T210000Z
   ATTENDEE;STATUS=Declined:Deriks@Microsoft.com
   REQUEST-STATUS:0;Success
   DTSTAMP:19970702T200000Z
   END:VTODO
   END:VCALENDAR

5.   Application Protocol Fallbacks


   Applications that support iTIP are not required to support the entire
   protocol. The following describes how profiles and properties should
   "fallback" in applications that do not support the complete protocol.
   If a profile or property is not addressed in this section, it may be
   safely ignored.

5.1  ICalendar Profile Types




        Profile           Fallback


        TODO-PUBLISH      Required.


        TODO-CANCEL       Required.


        TODO-REQUEST      TODO-PUBLISH


        TODO-REPLY        Required.




5.2  Calendar Components




        Component         Fallback


        VALARM            Reply with Not Supported.




Dawson/Hopson/Mansour/Silverberg   42              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997




        VTIMEZONE         Required if RRULE or RDATE is
                          implemented; otherwise ignore and use
                          local time.




5.3  Calendar Properties




        Property          Fallback


        CALSCALE          Ignore; assume GREGORIAN.


        GEO               Ignore.


        PRODID            Ignore.


        PROFILE           Required as described in the Profiles
                          section above.


        PROFILE-          Assume "1.0".
        VERSION


        SOURCE            Ignore


        NAME              Ignore.


        VERSION           Assume "2.0".




5.4  Component Properties




         Property        Fallback


         ATTACH          Ignore.


         ATTENDEE        Required if TODO-REQUEST is not
                          implemented; otherwise ignore.


         CATEGORIES      Ignore.


         CLASS           Ignore.


         COMMENT         Ignore.


         COMPLETED       Required.




Dawson/Hopson/Mansour/Silverberg   43              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997




         CREATED         Ignore.


         DAYLIGHT        Required if VTIMEZONE is implemented;
                          otherwise ignore.


         DESCRIPTION     Required.


         DUE             Required.


         DURATION        Ignore. Reply with Not Supported.


         DTSTART         Required.


         EXDATE          Ignore. Reply with Not Supported.


         EXRULE          Ignore. Reply with Not Supported.


         LAST-           Ignore.
         MODIFIED


         LOCATION        Ignore.


         PRIORITY        Required.


         RELATED-TO      Ignore.


         RDATE           Ignore. If implemented, VTIMEZONE must
                          also be implemented.


         RRULE           Ignore. The first instance occurs on
                          the DTStart property.


         RESOURCES       Ignore.


         RESPONSE-       Required.
         SEQUENCE


         SEQUENCE        Required.


         STATUS          Required.


         SUMMARY         Ignore.


         TRANSP          Required if FREEBUSY is implemented;
                          otherwise Ignore.


         TZNAME          Required if VTIMEZONE is implemented;
                          otherwise Ignore.


         TZOFFSET        Required if VTIMEZONE is implemented;
                          otherwise Ignore.



Dawson/Hopson/Mansour/Silverberg   44              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997




         TZTRANS         Required if VTIMEZONE is implemented;
                          otherwise Ignore.


         URL             Ignore.


         UID             Required.


         X-              Ignore.




5.5  Latency Issues


   With a store-and-forward transport, it is possible for requests to
   arrive out of sequence. That is, an implementation may receive a
   TODO-CANCEL notification prior to receiving the original to-do
   request. This section discusses a few of these scenarios.

5.5.1     Cancelation of an Unknown To-do.


   When a TODO-CANCEL request is received before the original TODO-
   REQUEST the calendar will be unable to correlate the UID of the
   cancellation with an existing to-do. It is suggested that messages
   that cannot be correlated that also contain non-zero sequence numbers
   be held and not discarded. Implementations can age them out if no
   other messages arrive with the same UID and a lower sequence number.

5.6  Sequence Number


   Under some conditions, a CUA may receive requests and replies with
   the same SEQUENCE number. DTSTAMP is added to act as a tiebreaker
   when two items with the same SEQUENCE number are evaluated.
   Furthermore, the SEQUENCE number is only incremented when one or more
   of the following properties changes:



    DTSTART

    DTEND (for Events)

    LOCATION

    DUE

6.   Security Considerations


   ITIP outlines an abstract transport protocol which will be bound to a
   real-time transport, a store-and-forward transport, and perhaps other
   transports. The transport protocol provides facilities for simple
   authentication using a clear text password, as well as any SASL
   mechanism [SASL]. SASL allows for integrity and privacy services to
   be negotiated.




Dawson/Hopson/Mansour/Silverberg   45              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   Use of clear text password is strongly discouraged where the
   underlying transport service cannot guarantee confidentiality and may
   result in disclosure of the password to unauthorized parties.

7.   Acknowledgments


   A hearty thanks to the following individuals who have participated in
   the drafting, review and discussion of this memo:

   Anik Ganguly, Bruce Kahn, Leo Parker, John Rose, Vinod Seraphin,
   Richard Shusterman, Derik Stenerson, Kevin Tsurutome.

8.   Bibliography


   [ID-DT] "Date and Time on the Internet", Internet-Draft, December
   1996, http://www.imc.org/draft-newman-datetime.

   [ICAL] "Internet Calendaring and Scheduling Core Object Specification
   - iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet-
   drafts/draft-ietf-calsch-ical-02.txt.

   [ICMS] "Internet Calendaring Model Specification", Internet-Draft,
   July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-
   00.txt.

   [ITIP-1] "iCalendar Transport-Independent Interoperability Protocol
   (iTIP) - Part 1: Scheduling Events and Busytime", Internet-Draft,
   July 1997, http://www.imc.org/draft-ietf-calsch-itip-part1-00.txt.

   [ITIP-2] "iCalendar Transport-Independent Interoperability Protocol
   (iTIP) - Part 2: Scheduling To-dos", Internet-Draft, July 1997,
   http://www.imc.org/draft-ietf-calsch-itip-part2-00.txt

   [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646",
   Internet-Draft, July,1996, ftp://ftp.ietf.org/internet-drafts/draft-
   yergeau-utf8-01.txt.

   [ISO8601] "Data elements and interchange formats - information
   interchange - Representation of dates and times", ISO 8601, 1996-06-
   15, +1 (212) 642-4900 for ANSI Sales.

   [RFC2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail
   Extensions - Part One - Format of Internet Message Bodies", RFC 2045,
   Innosoft, First Virtual, November 1996,
   http://www.imc.org/rfc2045.txt.

   [RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail
   Extensions - Part Two - Media Types", RFC 2046, Innosoft, First
   Virtual, November 1996, http://www.imc.org/rfc2046.txt.

   [UNICODE] The Unicode Consortium, "The Unicode Standard -Version
   2.0", Addison-Wesley Developers Press, July 1996. UTF-8 is described
   in section A-2.



Dawson/Hopson/Mansour/Silverberg   46              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   [US-ASCII] Coded Character Set--7-bit American Standard Code for
   Information Interchange, ANSI X3.4-1986.

9.   Authors Addresses


   The following address information is provided in a MIME-VCARD,
   Electronic Business Card, format.

   The authors of this draft are:

   BEGIN:VCARD
   FN:Frank Dawson
   ORG:Lotus Development Corporation
   ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613-
   3502;USA
   TEL;WORK;MSG:+1-919-676-9515
   TEL;WORK;FAX:+1-919-676-9564
   EMAIL;INTERNET:fdawson@earthlink.net
   URL:http://home.earthlink.net/~fdawson
   END:VCARD

   BEGIN:VCARD
   FN:Ross Hopson
   ORG:On Technology, Inc.
   ADR;WORK;POSTAL;PARCEL:Suite 1600;;434 Fayetteville St.
    Mall, Two Hannover Square;Raleigh;NC;27601
   TEL;WORK;MSG:+1-919-890-4036
   TEL;WORK;FAX:+1-919-890-4100
   EMAIL;INTERNET:rhopson@on.com
   END:VCARD

   BEGIN:VCARD
   FN:Steve Mansour
   ORG:Netscape Communications Corporation
   ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain
   View;CA;94043;USA
   TEL;WORK;MSG:+1-415-937-2378
   TEL;WORK;FAX:+1-415-428-4059
   EMAIL;INTERNET:sman@netscape.com
   END:VCARD

   BEGIN:VCARD
   FN:Steve Silverberg
   ORG:Microsoft Corporation
   ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way;
   Redmond;WA;98052-6399;USA
   TEL;WORK;MSG:+1-206-936-9277
   TEL;WORK;FAX:+1-206-936-8019
   EMAIL;INTERNET:stevesil@Exchange.Microsoft.com
   END:VCARD






Dawson/Hopson/Mansour/Silverberg   47              Expires January 1998



Internet Draft     iTIP Part Two - Scheduling To-dos      July 18, 1997


   The iCalendar Object is a result of the work of the Internet
   Engineering Task Force Calendaring and scheduling Working Group. The
   chairman of that working group is:

   BEGIN:VCARD
   FN:Anik Ganguly
   ORG:OnTime, Inc.
   ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern
   Highway;Southfield;MI;48075;USA
   TEL;WORK;MSG:+1-810-559-5955
   TEL;WORK;FAX:+1-810-559-5034
   EMAIL;INTERNET:anik@ontime.com
   END:VCARD











































Dawson/Hopson/Mansour/Silverberg   48              Expires January 1998