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

Versions: 00 01 02 03 04 05 06 07 rfc2447                               
Network Working Group                                Frank Dawson/Lotus
Internet Draft                                   Steve Mansour/Netscape
<draft-ietf-calsch-imip-01.txt>              Steve Silverberg/Microsoft
Expires six months after September12, 1997


           iCalendar Message-Based Interoperability Protocol
                                 (iMIP)


Status of this Memo


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

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

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

   Distribution of this document is unlimited.


Abstract


   This document specifies a binding from the iCalendar Transport-
   independent Interoperability Protocol [ITIP] to Internet email-based
   transports. Calendaring entries defined by the iCalendar Object Model
   [ICAL] are composed using constructs from [RFC-822], [RFC-2045],
   [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].

   This document is based on the calendaring and scheduling model
   defined by [ICMS].

   This document is based on discussions within the Internet Engineering
   Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.
   More information about the IETF CALSCH working group activities can
   be found on the IMC website at http://www.imc.org, the IETF website
   at http://www.ietf.org/html.charters/calsch-charter.html. Refer to
   the references within this document for further information on how to
   access these various documents.

   Distribution of this document is unlimited. Comments and suggestions
   for improvement should be sent to the authors.







Dawson/Mansour/Silverberg          1                 Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997

1  Introduction


   This binding document provides the transport specific information
   necessary convey iCalendar Transport-independent Interoperability
   Protocol [ITIP] over MIME as defined in [RFC-822] and [RFC-2045].

1.1 Related Memos


   Implementors will need to be familar with several other memos that,
   along with this memo, form a framework for Internet calendaring and
   scheduling standards.

   This document - specifies an Internet email binding for [ITIP].

   [ICMS] - specifies a common terminology and abstract;

   [ICAL] - specifies a core specification of objects, data types,
   properties and property parameters;

   [ITIP] - specifies an interoperability protocol for scheduling
   between different implementations;

   [IRIP] - specifies an Internet real time protocol binding for [ITIP].

   This memo does not attempt to repeat the specification of concepts or
   definitions from these other memos. Where possible, references are
   made to the memo that provides for the specification of these
   concepts or definitions.

1.2 Formatting Conventions


   The mechanisms defined in this memo are defined in propose. In order
   to refer to elements of the calendaring and scheduling model, core
   object or interoperability protocol defined in [ICMS], [ICAL] and
   [ITIP] some formatting conventions have been used.

   Calendaring and scheduling roles defined by [ICMS] are referred to in
   quoted-strings of text with the first character of each word in upper
   case. For example, "Organizer" refers to a role of a "Calendar User"
   within the scheduling protocol defined by [ITIP]

   Calendar components defined by [ICAL] are referred to with
   capitalized, quoted-strings of text. All calendar components start
   with the letter "V". For example, "VEVENT" refers to the event
   calendar component, "VTODO" refers to the to-do calendar component
   and "VJOURNAL" refers to the daily journal calendar component.

   Scheduling methods defined by [ITIP] are referred to with
   capitalized, quoted-strings of text. For example, "REQUEST" refers to
   the method for requesting a scheduling calendar component be created
   or modified, "REPLY" refers to the method a recipient of a request
   uses to update their status with the "Organizer" of the calendar
   component.



Dawson/Mansour/Silverberg          2                 Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997

   Properties defined by [ICAL] are referred to with capitalized,
   quoted-strings of text, followed by the word "property". For example,
   "ATTENDEE" property refers to the iCalendar property used to convey
   the calendar address of a calendar user.

   Property parameters defined by [ICAL] are referred to with lower
   case, quoted-strings of text, followed by the word "parameter". For
   example, "VALUE" parameter refers to the iCalendar property parameter
   used to override the default data type for a property value.

1.3 Terminology


   The email terms used in this memo are defined in [RFC-822] and [RFC-
   2045]. The calendaring and scheduling terms used in this memo are
   defined in [ICMS], [ICAL] and [ITIP]

2  MIME Message Format Binding


   This section defines the message binding to the MIME electronic mail
   transport.

   The sections below refer to the "originator" and the "respondent" of
   an iMIP message. Typically, the originator is the owner or oganizer
   of an event. The respondent is an attendee of the event.

   In a well-organized email message the Reply-To header contains the
   email address of the originator or respondent of an event. However,
   this cannot be guaranteed as Mail User Agents (MUA) are not required
   to enforce iMIP semantics.

2.1 MIME Media Type


   A MIME entity containing content information formatted according to
   this design document will be referenced as a "text/calendar" content
   type. It is assumed that this content type will be transported
   through a MIME electronic mail transport.

2.2 Security


   This section addresses several aspects of security including
   Authentication, Authorization and Confidentiality. Authentication and
   confidentiality can be achieved using RFC 1847 which specifies the
   Security Multiparts for MIME. This framework defines new content
   types and subtypes of multipart: signed and encrypted. Each contains
   two body parts: one for the protected data and another for the
   control information necessary to remove the protection.

2.2.1   Authorization


   Per the [ICSM], only the organizer has authorization to modify or
   cancel calendar entries they organize. That is, spoof@xyz.com should
   not be able to modify or cancel a meeting that was organized by



Dawson/Mansour/Silverberg          3                 Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997

   a@xyz.com. Furthermore, only the respondent has the authorization to
   indicate their status to the organizer. That is, spoof@xyz.com should
   not be able to tell the organizer that b@xyz.com declines a meeting
   invitation.

   [Editors note: this does not address issues around a calendar user
   assigning someone else as a delegate to accept or decline meetings on
   their behalf. For example, suppose an event invitation is sent to Joe
   (joe@x.com). Mary (mary@x.com), Joe’s administrative assistant,
   accepts the meeting on Joe’s behalf. How is this handled in the iTIP
   realm? Should the "From:" and/or "Reply-To" fields contain joe@x.com
   or mary@x.com? How is the organizer of the meeting to know that Mary
   can accept meetings on Joe’s behalf?]

   Hence, iMIP implementations must verify the authenticity of the
   sender of an iCalendar object before taking any action. This could be
   done by utilizing a Multipart/signed implementation of either
   PGP/MIME or S/MIME.

   [Editors note: this needs further clarification. How do you do this?
   The certificate owner must be somehow correlated to the organizer or
   the respondent. How is this done?]

2.2.2   Authentication


   Authentication can be performed using an implementation of RFC 1847
   Multipart/signed that supports public/private key certificates.
   However, since most MUAs provide for the forwarding of messages, the
   organizer of an event and the sender of the message may be different.
   Therefore authentication may not be possible.

2.2.3   Confidentiality


   To ensure confidentiality using iMIP implementations should utilize
   RFC 1847 compliant encryption. The protocol does not restrict a CUA
   from forwarding Requests or Responses to other users or agents.

2.3 RFC 822 Addresses


   The calendar address specified within the "ATTENDEE" property in an
   iCalendar object MUST be a fully qualified, RFC 822 address for the
   corresponding "Owner", "Organizer" or "Attendee" of the "VEVENT" or
   "VTODO". The address MUST be the RFC 822 address for the calendaring
   and scheduling mailbox for the attendee.

   For purposes of authentication and authorization the RFC 822 "Sender"
   and "Reply-to" value MUST be the same as the address value for the
   "Organizer". Because [ITIP] does not preclude "Attendees" from
   forwarding "VEVENTS" or "VTODOS" to others, the RFC-822 "Sender"
   value may not equal that of the organizer. In these cases,
   authentication cannot be verified. Additionally, the "Organizer"
   cannot be inferred by the RFC-822 "Sender" or "Reply-to" values.




Dawson/Mansour/Silverberg          4                 Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997

   Instead, it MUST be derived by opening the proper text/calendar MIME
   body part.

2.4 Content Type


   A MIME body part containing content information that conforms to this
   design document MUST have a Content-Type value of "text/calendar".
   The content type header field MUST also include the type parameter
   "method". The parameter value MUST be one of the message types
   defined by this method. The value MUST also be the same as the value
   of the METHOD calendar property within the iCalendar object. This
   means that if a MIME message containing multiple iCalendar objects
   with different method values, then they must be further encapsulated
   with a "multipart/mixed" MIME entity. This will allow each of the
   iCalendar objects to be encapsulated within their own "text/calendar"
   MIME entity.

   The Content-Type CHARSET parameter MUST appear in any MIME entity
   encapsulating an iCalendar object conforming to this design document.
   The CHARSET parameter value MUST be "UTF-8" or some other valid
   character set. The reason for this is that in [iCal] the default
   character set is UTF-8.

   The optional Content-Type COMPONENT parameter defines the iCalendar
   component type contained within the iCalendar object.

   The following is an example of this header field with a value that
   indicates an event request message.

        Content-Type:text/calendar; method=request; charset=UTF-8;
              component=vevent

   The "text/calendar" content type allows for the scheduling message
   type to be included in a MIME message with other content information
   (i.e., multipart/mixed) or included in a MIME message with a clear-
   text, human-readable form of the scheduling message (i.e.,
   multipart/alternative).

   In order to permit the information in the scheduling message to be
   understood by MIME user agents (UA) that do not support the
   text/calendar content type, scheduling messages should be sent with
   an alternative, human-readable form of the information.

2.5 Content-Transfer-Encoding


   Note that the default character set for iCalendar objects is UTF-8
   and a transfer encoding may be required.

        Content-Transfer-Encoding:quoted-printable

2.6 Content-Description


   The Content-Description header is optional.



Dawson/Mansour/Silverberg          5                 Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997


        Content-Description: iCalendar REQUEST for an event

3  Examples


   In the examples below, the iCalendar object does not specify a
   character set, it is assumed to be UTF-8. Quoted-printable has been
   used to keep the message human readable.

3.1 Single Component With An ATTACH Property


   This minimal message shows a how a an iCalendar object references an
   attachment. The attachment is accessible by anyone via its URL.

   From: sman@netscape.com
   To: stevesil@microsoft.com
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type:text/calendar; method=REQUEST; charset=UTF-8
   Content-Transfer-Encoding:quoted-printable

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:sman@netscape.com
   ATTENDEE;RSVP=YES;EXPECT=REQUEST:stevesil@microsoft.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T100000-0700
   DTEND:19970701T103000-0700
   SUMMARY:Phone Conference
   DESCRIPTION:Please review the attached document.
   UID:www.acme.com-873970198738777
   ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR


3.2 Single Component With An ATTACH Property and Inline Attachment


   This example shows how a message containing an iCalendar object
   references an attached document. The reference is made using a
   Content-id (CID). Thus, the iCalendar object and the document are
   packaged in a multipart/related encapsulation.

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type: multipart/related; boundary="boundary-example-1";



Dawson/Mansour/Silverberg          6                 Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997

                 type=text/calendar

   --boundary-example-1

   Content-Type:text/calendar; method=REQUEST; charset=UTF-8
   Content-Transfer-Encoding: quoted-printable
   Content-Disposition: attachment; filename="event.vcs"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:foo1@bar.net
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;
    TYPE=INDIVIDUAL:foo2@bar.net
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T100000-0700
   DTEND:19970701T103000-0700
   SUMMARY:Phone Conference
   UID:www.acme.com-873970198738777
   ATTACH:cid:www.acme.com-12345aaa
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   --boundary-example-1
   Content-Type: application/msword; name="FieldReport.doc"
   Content-Transfer-Encoding: base64
   Content-Disposition: inline; filename="FieldReport.doc"
   Content-ID: <www.acme.com-12345aaa>

   0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////e
   tc...

   --boundary-example-1--

3.3 Multiple Similar Components


   Multiple iCalendar components can be included in the iCalendar object
   when the METHOD is the same for each component.

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type:text/calendar; method=REQUEST; charset=UTF-8
   Content-Transfer-Encoding: quoted-printable
   Content-Disposition: attachment; filename="event.vcs"

   BEGIN:VCALENDAR



Dawson/Mansour/Silverberg          7                 Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997

   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:foo1@bar.net
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:foo2@bar.net
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T100000-0700
   DTEND:19970701T103000-0700
   SUMMARY:Phone Conference
   DESCRIPTION:Discuss the contents of the attached document
   UID:www.acme.com-873970198738777
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   BEGIN:VEVENT
   ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:foo1@bar.net
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:foo2@bar.net
   DTSTAMP:19970611T190000Z
   DTSTART:19970801T100000-0700
   DTEND:19970801T103000-0700
   SUMMARY:Follow-up Phone Conference
   DESCRIPTION:Discuss the contents of the attached document
   UID:www.acme.com-873970198738777
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR


3.4 Multiple Mixed Components


   Different component types must be encapsulated in separate iCalendar
   objects.

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C"

   This is a multi-part message in MIME format.
   ----FEE3790DC7E35189CA67CE2C
   Content-Type:text/calendar; method=REQUEST; charset=UTF-8
   Content-Transfer-Encoding: quoted-printable
   Content-Disposition: attachment; filename="event.vcs"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:foo1@bar.net



Dawson/Mansour/Silverberg          8                 Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997

   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:foo2@bar.net
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T100000-0700
   DTEND:19970701T103000-0700
   SUMMARY:Phone Conference
   DESCRIPTION:Discuss the contents of the attached document
   UID:www.acme.com-873970198738777
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   ----FEE3790DC7E35189CA67CE2C
   Content-Type:text/calendar; method=REQUEST; charset=UTF-8
   Content-Transfer-Encoding:8bit
   Content-Disposition: attachment; filename="event.vcs"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VTODO
   DUE:19970701T090000-0700
   SUMMARY:Phone Conference
   DESCRIPTION:Discuss the contents of the attached document
   UID:www.acme.com-td-873970198738777
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   ----FEE3790DC7E35189CA67CE2C

3.5 Detailed Components With An ATTACH Property


   This example shows the format of a message containing a group meeting
   between three individuals. The multipart/related encapsulation is
   used because the iCalendar object contains an ATTACH property that
   uses a CID to reference the attachment.

   From: Steve Mansour <sman@netscape.com>
   MIME-Version: 1.0
   To: Steve Silverberg <stevesil@exchange.microsoft.com>,
        Frank Dawson <fdawson@earthlink.net>
   Subject: REQUEST - Phone Conference
   Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C"

   This is a multi-part message in MIME format.
   ----FEE3790DC7E35189CA67CE2C
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit

   Event REQUEST



Dawson/Mansour/Silverberg          9                 Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997


   Decription:
   Let’s discuss the attached document

   Begin: July 1, 1997  10:00 PDT
   End: July 1, 1997  10:30 PDT
   ----FEE3790DC7E35189CA67CE2C
   Content-Type: multipart/related; boundary="boundary-example-2";
                 type=text/calendar

   --boundary-example-2
   Content-Type:text/calendar; method=REQUEST; charset=UTF-8;
                 Component=vevent
   Content-Transfer-Encoding: quoted-printable
   Content-Disposition: attachment; filename="event.vcs"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   PROFILE:REQUEST
   PROFILE-VERSION:1.0
   VERSION:2.0
   BEGIN:VEVENT
   ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:foo1@bar.net
   ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:foo2@bar.net
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T100000-0700
   DTEND:19970701T103000-0700
   SUMMARY:Let’s discuss the attached document
   UID:www.acme.com-873970198738777
   ATTACH:cid:www.acme.com-12345aaa
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   --boundary-example-2
   Content-Type: application/msword; name="FieldReport.doc"
   Content-Transfer-Encoding: base64
   Content-Disposition: inline; filename="FieldReport.doc"
   Content-ID: <www.acme.com-12345aaa>

   0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////e
   tc...

   --boundary-example-2--
   ----FEE3790DC7E35189CA67CE2C--









Dawson/Mansour/Silverberg          10                Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997

4  Bibliography


   [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] This currently includes the following three documents that are
   being merged into a single iTIP document.

        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.

        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

        3. "iCalendar Transport-Independent Interoperability Protocol
        (iTIP) - Part 3: Scheduling Journal Entries", Internet-Draft,
        July 1997, http://www.imc.org/draft-ietf-calsch-itip-part3-
        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.

   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
   Messages", STD 11, RFC 822, August 1982.

   [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security
   Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC
   1847, October 1995.

   [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type,"
   RFC 2112, March 1997.

   [RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP),"
   RFC 2015, October 1996.

   [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail
   Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC
   2045, November 1996.

   [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail
   Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996.






Dawson/Mansour/Silverberg          11                Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997

   [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) -
   Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
   November 1996.

   [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet
   Mail Extensions (MIME) - Part Four: Registration Procedures", RFC
   2048, January 1997.

5  Author's Address


   The following address information is provided in a vCard v2.1,
   Electronic Business Card, format.

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

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

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

   BEGIN:VCARD
   FN:Anik Ganguly
   ORG:OnTime, Inc.
   ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern
   Highway;Southfield;MI;48075;USA



Dawson/Mansour/Silverberg          12                Expires March 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                           September 12, 1997

   TEL;WORK;MSG:+1-810-559-5955
   TEL;WORK;FAX:+1-810-559-5034
   EMAIL;INTERNET:anik@ontime.com
   END:VCARD




















































Dawson/Mansour/Silverberg          13                Expires March 1998