[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-02.txt>              Steve Silverberg/Microsoft
Expires six months after                               October 24, 1997


           iCalendar Message-Based Interoperability Protocol
                                 (iMIP)


Status of this Memo


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

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

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

   Distribution of this document is unlimited.


Abstract


   This document 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 May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 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 May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 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 May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 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.

   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.

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
   specification 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.
   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


Dawson/Mansour/Silverberg          4                   Expires May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 1997

   with a "multipart/mixed" MIME entity. This will allow each of the
   iCalendar objects to be encapsulated within their own "text/calendar"
   MIME entity.

   A CHARSET parameter MUST be present when the "text/calendar" is used.
   RFC-2046 discusses the selection of an appropriate CHARSET value.

   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 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. A
   transfer encoding SHOULD be used for iCalendar objects containing any
   characters that are not part of the US-ASCII character set.

        Content-Transfer-Encoding:quoted-printable

3  Security Considerations


   [ITIP] details the security threats that applications must address
   when implementing ITIP.  Two spoofing threats are identified:
   Spoofing the "Organizer", and Spoofing an "Attendee". To address
   these threats, the originator of an iCalendar object must be
   authenticated by a recipient. Once authenticated, a determination can
   be made as to whether or not the originator is authorized to perform
   the requested operation. Applications requiring protection from this
   type of threat SHOULD provide a mechanism based on Security
   Multiparts for MIME [RFC1847] to authenticate the originator of the
   iCalendar object. The steps are described  below:

   1. The iCalendar object must be signed by the "Organizer" sending an
   update or the "Attendee" sending a reply.

   2.  Using the RFC1847-compliant security mechanism, determine who
   signed the iCalendar object. This is the "signer". Note that the



Dawson/Mansour/Silverberg          5                   Expires May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 1997

   signer is not necessarily the person sending an e-mail message.  An
   e-mail message can be forwarded.

   3. Correlate the "signer" to an "ATTENDEE" property in the iCalendar
   object.  If the signer cannot be correlated to an "ATTENDEE"
   property, ignore the message.

   4. Determine whether or not the "ATTENDEE" is authorized to perform
   the operation. ITIP states:

   (a) the "Organizer" is the only person authorized to make changes
       to an existing "VEVENT", "VTODO", "VJOURNAL" calendar component
       and redistribute the updates to the "Attendees"

   (b) an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL" calendar
       component is the only person authorized to update any parameter
       associated with their "ATTENDEE" property and send it to the
       "Organizer"

   If these conditions are not met, ignore the message.

   5. If all the above conditions are met, the message can be processed.

4  Examples


4.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=US-ASCII
   Content-Transfer-Encoding: 7bit

   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



Dawson/Mansour/Silverberg          6                   Expires May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 1997

   END:VEVENT
   END:VCALENDAR


4.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";
                 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\:123456789@example.com
   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: <123456789@example.com>

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




Dawson/Mansour/Silverberg          7                   Expires May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 1997

   --boundary-example-1--

4.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=US-ASCII
   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
   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


4.4 Multiple Mixed Components


   Different component types must be encapsulated in separate iCalendar
   objects.

   From: foo1@bar.net
   To: foo2@bar.net



Dawson/Mansour/Silverberg          8                   Expires May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 1997

   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=US-ASCII
   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
   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=US-ASCII
   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

4.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



Dawson/Mansour/Silverberg          9                   Expires May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 1997

   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

   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=US-ASCII;
                 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


Dawson/Mansour/Silverberg          10                  Expires May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 1997

   Content-Disposition: inline; filename="FieldReport.doc"
   Content-ID: <www.acme.com-12345aaa>

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

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


5  Bibliography


   [CHST] Character Sets, ftp://ftp.isi.edu/in-
   notes/iana/assignments/character-sets

   [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] "iCalendar Transport-Independent Interoperability Protocol
   (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ",
   Internet-Draft, October 1997, http://www.imc.org/draft-ietf-calsch-
   itip-01.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 May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 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.

6  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 May 1998



Internet DraftiCalendar Message-based Interoperability Protocol (iMIP)
                            October 24, 1997

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

7  Full Copyright Statement


   "Copyright (C) The Internet Society (date).  All Rights Reserved.

   This document and translations of it MAY be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation MAY be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself MAY NOT be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process MUST be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Dawson/Mansour/Silverberg          13                  Expires May 1998