summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3283.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3283.txt')
-rw-r--r--doc/rfc/rfc3283.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc3283.txt b/doc/rfc/rfc3283.txt
new file mode 100644
index 0000000..1960f92
--- /dev/null
+++ b/doc/rfc/rfc3283.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group B. Mahoney
+Request for Comments: 3283 MIT
+Category: Informational G. Babics
+ Steltor
+ A. Taler
+ June 2002
+
+
+ Guide to Internet Calendaring
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document describes the various Internet calendaring and
+ scheduling standards and works in progress, and the relationships
+ between them. Its intent is to provide a context for these
+ documents, assist in their understanding, and potentially aid in the
+ design of standards-based calendaring and scheduling systems. The
+ standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and
+ RFC 2447 (iMIP). The work in progress addressed is "Calendar Access
+ Protocol" (CAP). This document also describes issues and problems
+ that are not solved by these protocols, and that could be targets for
+ future work.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.2 Concepts and Relationships . . . . . . . . . . . . . . . . . 4
+ 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1 Fundamental Needs . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2 Protocol Requirements . . . . . . . . . . . . . . . . . . . 5
+ 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.2.1 Standalone Single-user System . . . . . . . . . . . . . . . 8
+ 3.2.2 Single-user Systems Communicating . . . . . . . . . . . . . 8
+ 3.2.3 Single-user with Multiple CUAs . . . . . . . . . . . . . . . 9
+ 3.2.4 Single-user with Multiple Calendars . . . . . . . . . . . . 9
+
+
+
+Mahoney, et. al. Informational [Page 1]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+ 3.2.5 Users Communicating on a Multi-user System . . . . . . . . . 10
+ 3.2.6 Users Communicating through Different Multi-user Systems . . 10
+ 4. Important Aspects . . . . . . . . . . . . . . . . . . . . . 10
+ 4.1 Timezones . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 4.2 Choice of Transport . . . . . . . . . . . . . . . . . . . . 11
+ 4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.4 Amount of data . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.5 Recurring Components . . . . . . . . . . . . . . . . . . . . 11
+ 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.1 Scheduling People, not Calendars . . . . . . . . . . . . . . 12
+ 5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . 12
+ 6.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . 12
+ 6.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 12
+ 6.3 Using E-mail . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.4 Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 13
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13
+ References . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
+
+1. Introduction
+
+ Calendaring and scheduling protocols are intended to aid individuals
+ in obtaining calendaring information and scheduling meetings across
+ the Internet, to aid organizations in providing calendaring
+ information on the Internet, and to provide for organizations looking
+ for a calendaring and scheduling solution to deploy internally.
+
+ It is the intent of this document to provide a context for these
+ documents, assist in their understanding, and potentially help in the
+ design of standards-based calendaring and scheduling systems.
+
+ Problems not solved by these protocols, as well as security issues to
+ be kept in mind, are discussed at the end of the document.
+
+1.1 Terminology
+
+ This memo uses much of the same terminology as iCalendar [RFC-2445],
+ iTIP [RFC-2446], iMIP [RFC-2447], and [CAP]. The following
+ definitions are provided as an introduction; the definitions in the
+ protocol specifications themselves should be considered canonical.
+
+
+
+
+
+
+
+
+Mahoney, et. al. Informational [Page 2]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+ Calendar
+
+ A collection of events, to-dos, journal entries, etc. A calendar
+ could be the content of a person or resource's agenda; it could
+ also be a collection of data serving a more specialized need.
+ Calendars are the basic storage containers for calendaring
+ information.
+
+ Calendar Access Rights
+
+ A set of rules defining who may perform what operations, such as
+ reading or writing information, on a given calendar.
+
+ Calendar Service
+
+ A running server application that provides access to a number of
+ calendar stores.
+
+ Calendar Store (CS)
+
+ A data store of a calendar service. A calendar service may have
+ several calendar stores, and each store may contain several
+ calendars, as well as properties and components outside of those
+ calendars.
+
+ Calendar User (CU)
+
+ An entity (often a human) that accesses calendar information.
+
+ Calendar User Agent (CUA)
+
+ Software with which the calendar user communicates with a calendar
+ service or local calendar store to access calendar information.
+
+ Component
+
+ A piece of calendar data such as an event, a to-do or an alarm.
+ Information about components is stored as properties of those
+ components.
+
+ Delegator
+
+ A calendar user who has assigned his or her participation in a
+ scheduled calendar component (e.g. a VEVENT) to another calendar
+ user (sometimes called the delegate or delegatee). An example of
+ a delegator is a busy executive sending an employee to a meeting
+ in his or her place.
+
+
+
+
+Mahoney, et. al. Informational [Page 3]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+ Delegate
+
+ A calendar user (sometimes called the delegatee) who has been
+ assigned to participate in a scheduled calendar component (e.g. a
+ VEVENT) in place of one of the attendees in that component
+ (sometimes called the delegator). An example of a delegate is a
+ team member sent to a particular meeting.
+
+ Designate
+
+ A calendar user authorized to act on behalf of another calendar
+ user. An example of a designate is an assistant scheduling
+ meetings for his or her superior.
+
+ Local Store
+
+ A CS that is on the same device as the CUA.
+
+ Property
+
+ A description of some element of a component, such as a start
+ time, title or location.
+
+ Remote Store
+
+ A CS that is not on the same device as the CUA.
+
+1.2 Concepts and Relationships
+
+ iCalendar is the language used to describe calendar objects. iTIP
+ describes a way to use the iCalendar language to do scheduling. iMIP
+ describes how to do iTIP scheduling via e-mail. CAP describes a way
+ to use the iCalendar language to access a calendar store in real-
+ time.
+
+ The relationship between calendaring protocols is similar to that
+ between e-mail protocols. In those terms, iCalendar is analogous to
+ RFC 2822, iTIP and iMIP are analogous to the Simple Mail Transfer
+ Protocol (SMTP), and CAP is analogous to the Post Office Protocol
+ (POP) or Internet Message Access Protocol (IMAP).
+
+2. Requirements
+
+2.1 Fundamental Needs
+
+ The following scenarios illustrate people and organizations' basic
+ calendaring and scheduling needs:
+
+
+
+
+Mahoney, et. al. Informational [Page 4]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+ a] A doctor wishes to keep track of all her appointments.
+
+ Need: To read and manipulate one's own calendar with only one CUA.
+
+ b] A busy musician wants to maintain her schedule with multiple
+ devices, such as through an Internet-based agenda and with a PDA.
+
+ Need: To read and manipulate one's own calendar, possibly with
+ solutions from different vendors.
+
+ c] A software development team wishes to more effectively schedule
+ their time through viewing each other's calendar information.
+
+ Need: To share calendar information between users of the same
+ calendar service.
+
+ d] A teacher wants his students to schedule appointments during
+ his office hours.
+
+ Need: To schedule calendar events, to-dos and journals with other
+ users of the same calendar service.
+
+ e] A movie theater wants to publish its schedule for prospective
+ customers.
+
+ Need: To share calendar information with users of other calendar
+ services, possibly from a number of different vendors.
+
+ f] A social club wants to schedule calendar entries effectively
+ with its members.
+
+ Need: To schedule calendar events and to-dos with users of other
+ calendar services, possibly from a number of different vendors.
+
+2.2 Protocol Requirements
+
+ Some of these needs can be met by proprietary solutions (a, c, d),
+ but others can not (b, e, f). These latter scenarios show that
+ standard protocols are required for accessing information in a
+ calendar store and scheduling calendar entries. In addition, these
+ protocols require a common data format for representing calendar
+ information.
+
+ These requirements are met by the following protocol specifications.
+
+
+
+
+
+
+
+Mahoney, et. al. Informational [Page 5]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+ - Data format: iCalendar [RFC-2445]
+
+ iCalendar [RFC-2445] provides a data format for representing
+ calendar information, to be used and exchanged by other protocols.
+ iCalendar [RFC-2445] can also be used in other contexts, such as a
+ drag-and-drop interface, or an export/import feature. All the
+ other calendaring protocols depend on iCalendar [RFC-2445], so all
+ elements of a standards-based calendaring and scheduling systems
+ will have to be able to interpret iCalendar [RFC-2445].
+
+ - Scheduling protocol: iTIP [RFC-2446]
+
+ iTIP [RFC-2446] describes the messages used to schedule calendar
+ events. Within iTIP messages, events are represented in iCalendar
+ [RFC-2445] format, and have semantics that identify the message as
+ being an invitation to a meeting, an acceptance of an invitation,
+ or the assignment of a task.
+
+ iTIP [RFC-2446] messages are used in the scheduling workflow,
+ where users exchange messages in order to organize things such as
+ events and to-dos. CUAs generate and interpret iTIP [RFC-2446]
+ messages at the direction of the calendar user. With iTIP [RFC-
+ 2446] users can create, modify, delete, reply to, counter, and
+ decline counters to the various iCalendar [RFC-2445] components.
+ Furthermore, users can also request the free/busy time of other
+ people.
+
+ iTIP [RFC-2446] is transport-independent, and has one specified
+ transport binding: iMIP [RFC-2447] binds iTIP to e-mail. In
+ addition [CAP] will provide a real-time binding of iTIP [RFC-
+ 2446], allowing CUAs to perform calendar management and scheduling
+ over a single connection.
+
+ - Calendar management protocol: [CAP]
+
+ [CAP] describes the messages used to manage calendars on a
+ calendar store. These messages use iCalendar [RFC-2445] to
+ describe various components such as events and to-dos. These
+ messages make it possible to perform iTIP [RFC-2446] operations,
+ as well as other operations relating to a calendar store such as
+ searching, creating calendars, specifying calendar properties, and
+ specifying calendar access rights.
+
+
+
+
+
+
+
+
+
+Mahoney, et. al. Informational [Page 6]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+3. Solutions
+
+3.1 Examples
+
+ Returning to the scenarios presented in section 2.1, the calendaring
+ protocols can be used in the following ways:
+
+ a] The doctor can use a proprietary CUA with a local store, and
+ perhaps use iCalendar [RFC-2445] as a storage mechanism. This
+ would allow her to easily import her data store into another
+ application that supports iCalendar [RFC-2445].
+
+ b] The musician who wishes to access her agenda from anywhere can
+ use a [CAP]-enabled calendar service accessible over the Internet.
+ She can then use any available [CAP] clients to access the data.
+
+ A proprietary system that provides access through a Web-based
+ interface could also be employed, but the use of [CAP] would be
+ superior in that it would allow the use of third party
+ applications, such as PDA synchronization tools.
+
+ c] The development team can use a calendar service which supports
+ [CAP], and each member can use a [CAP]-enabled CUA of their
+ choice.
+
+ Alternatively, each member could use an iMIP [RFC-2447]-enabled
+ CUA, and they could book meetings over e-mail. This solution has
+ the drawback that it is difficult to examine other users' agendas,
+ making the organization of meetings more difficult.
+
+ Proprietary solutions are also available, but they require that
+ all members use clients by the same vendor, and disallow the use
+ of third party applications.
+
+ d] The teacher can set up a calendar service, and have students
+ book time through any of the iTIP [RFC-2446] bindings. [CAP]
+ provides real-time access, but could require additional
+ configuration. iMIP [RFC-2447] would be the easiest to configure,
+ but may require more e-mail processing.
+
+ If [CAP] access is provided then determining the state of the
+ teacher's schedule is straightforward. If not, this can be
+ determined through iTIP [RFC-2446] free/busy requests. Non-
+ standard methods could also be employed, such as serving up
+ iCalendar [RFC-2445], HTML, or XML over HTTP.
+
+ A proprietary system could also be used, but would require that
+ all students be able to use software from a specific vendor.
+
+
+
+Mahoney, et. al. Informational [Page 7]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+ e] [CAP] would be preferred for publishing a movie theater's
+ schedule, since it provides advanced access and search
+ capabilities. It also allows easy integration with customers'
+ calendar systems.
+
+ Non-standard methods such as serving data over HTTP could also be
+ employed, but would be harder to integrate with customers'
+ systems.
+
+ Using a completely proprietary solution would be very difficult,
+ if not impossible, since it would require every user to install
+ and use the proprietary software.
+
+ f] The social club could distribute meeting information in the
+ form of iTIP [RFC-2446] messages, sent via e-mail using iMIP
+ [RFC-2447]. The club could distribute meeting invitations, as
+ well as a full published agenda.
+
+ Alternatively, the club could provide access to a [CAP]-enabled
+ calendar service. However, this solution would be more expensive
+ since it requires the maintenance of a server.
+
+3.2 Systems
+
+ The following diagrams illustrate possible systems and their usage of
+ the various protocols.
+
+3.2.1 Standalone Single-user System
+
+ A single user system that does not communicate with other systems
+ need not employ any of the protocols. However, it may use iCalendar
+ [RFC-2445] as a data format in some places.
+
+ ----------- O
+ | CUA w/ | -+- user
+ |local store| A
+ ----------- / \
+
+3.2.2 Single-user Systems Communicating
+
+ Users with single-user systems may schedule meetings with each others
+ using iTIP [RFC-2446]. The easiest binding of iTIP [RFC-2446] to use
+ would be iMIP [RFC-2447], since messages can be held in the users'
+ mail queues, which we assume to already exist. [CAP] could also be
+ used.
+
+
+
+
+
+
+Mahoney, et. al. Informational [Page 8]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+ O ----------- ----------- O
+ -+- | CUA w/ | -----[iMIP]----- | CUA w/ | -+- user
+ A |local store| Internet |local store| A
+ / \ ----------- ----------- / \
+
+3.2.3 Single-user with Multiple CUAs
+
+ A single user may use more than one CUA to access his or her
+ calendar. The user may use a PDA, a Web client, a PC, or some other
+ device, depending on accessibility. Some of these clients may have
+ local stores and others may not. Those with local stores need to
+ synchronize the data on the CUA with the data on the CS.
+
+ -----------
+ | CUA w | -----[CAP]----------+
+ |local store| |
+ O ----------- ----------
+ -+- | CS |
+ A | |
+ / \ ----------
+ ----------- |
+ | CUA w/o | -----[CAP]----------+
+ |local store|
+ -----------
+
+3.2.4 Single-user with Multiple Calendars
+
+ A single user may have many independent calendars; for example, one
+ may contain work-related information and another personal
+ information. The CUA may or may not have a local store. If it does,
+ then it needs to synchronize the data of the CUA with the data on
+ both of the CS.
+
+ ----------
+ +------------[CAP]------ | CS |
+ | | |
+ O ----------- ----------
+ -+- | CUA |
+ A | |
+ / \ -----------
+ | ----------
+ +------------[CAP]------ | CS |
+ | |
+ ----------
+
+
+
+
+
+
+
+Mahoney, et. al. Informational [Page 9]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+3.2.5 Users Communicating on a Multi-user System
+
+ Users on a multi-user system may schedule meetings with each other
+ using [CAP]-enabled CUAs and services. The CUAs may or may not have
+ local stores. Those with local stores need to synchronize the data
+ on the CUAs with the data on the CS.
+
+ O -----------
+ -+- | CUA w | -----[CAP]----------+
+ A |local store| |
+ / \ ----------- ----------
+ | CS |
+ | |
+ ----------
+ O ----------- |
+ -+- | CUA w/o | -----[CAP]----------+
+ A |local store|
+ / \ -----------
+
+3.2.6 Users Communicating through Different Multi-user Systems
+
+ Users on a multi-user system may need to schedule meetings with users
+ on a different multi-user system. The services can communicate using
+ [CAP] or iMIP [RFC-2447].
+
+ O ----------- ----------
+ -+- | CUA w | -----[CAP]-------| CS |
+ A |local store| | |
+ / \ ----------- ----------
+ |
+ [CAP] or [iMIP]
+ |
+ O ----------- ----------
+ -+- | CUA w/o | -----[CAP]-------| CS |
+ A |local store| | |
+ / \ ----------- ----------
+
+4. Important Aspects
+
+ There are a number of important aspects of these calendaring
+ standards of which people, especially implementers, should be aware.
+
+4.1 Timezones
+
+ The dates and times in components can refer to a specific time zone.
+ Time zones can be defined in a central store, or they may be defined
+ by a user to fit his or her needs. All users and applications should
+ be aware of time zones and time zone differences. New time zones may
+
+
+
+Mahoney, et. al. Informational [Page 10]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+ need to be added, and others removed. Two different vendors may
+ describe the same time zone differently (such as by using a different
+ name).
+
+4.2 Choice of Transport
+
+ There are issues to be aware of in choosing between a network
+ protocol such as [CAP], or a store and forward protocol, such as iMIP
+ [RFC-2447].
+
+ The use of a network ("on-the-wire") mechanism may require some
+ organizations to make provisions to allow calendaring traffic to
+ traverse a corporate firewall on the required ports. Depending on
+ the organizational culture, this may be a challenging social
+ exercise.
+
+ The use of an email-based mechanism exposes time-sensitive data to
+ unbounded latency. Large or heavily utilized mail systems may
+ experience an unacceptable delay in message receipt.
+
+4.3 Security
+
+ See the "Security Considerations" (Section 6) section below.
+
+4.4 Amount of data
+
+ In some cases, a component may be very large, for instance, a
+ component with a very large attachment. Some applications may be
+ low-bandwidth or may be limited in the amount of data they can store.
+ Maximum component size may be set in [CAP]. It can also be
+ controlled in iMIP [RFC-2447] by restricting the maximum size of the
+ e-mail that the application can download.
+
+4.5 Recurring Components
+
+ In iCAL [RFC-2445], one can specify complex recurrence rules for
+ VEVENTs, VTODOs, and VJOURNALs. One must be careful to correctly
+ interpret these recurrence rules and pay extra attention to being
+ able to interoperate using them.
+
+5. Open Issues
+
+ Many issues are not currently resolved by these protocols, and many
+ desirable features are not yet provided. Some of the more prominent
+ ones are outlined below.
+
+
+
+
+
+
+Mahoney, et. al. Informational [Page 11]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+5.1 Scheduling People, not Calendars
+
+ Meetings are scheduled with people; however, people may have many
+ calendars, and may store these calendars in many places. There may
+ also be many routes to contact them. The calendaring protocols do
+ not attempt to provide unique access for contacting a given person.
+ Instead, 'calendar addresses' are booked, which may be e-mail
+ addresses or individual calendars. It is up to the users themselves
+ to orchestrate mechanisms to ensure that the bookings go to the right
+ place.
+
+5.2 Administration
+
+ The calendaring protocols do not address the issues of administering
+ users and calendars on a calendar service. This must be handled by
+ proprietary mechanisms for each implementation.
+
+5.3 Notification
+
+ People often wish to be notified of upcoming events, new events, or
+ changes to existing events. The calendaring protocols do not attempt
+ to address these needs in a real-time system. Instead, the ability
+ to store alarm information on events is provided, which can be used
+ to provide client-side notification of upcoming events. To organize
+ notification of new or changed events, clients have to poll the data
+ store.
+
+6. Security Considerations
+
+6.1 Access Control
+
+ There has to be reasonable granularity in the configuration options
+ for access to data through [CAP], so that what should be released to
+ requesters is released, and what shouldn't is not. Details of
+ handling this are described in [CAP].
+
+6.2 Authentication
+
+ Access control must be coupled with a good authentication system, so
+ that the right people get the right information. For [CAP], this
+ means requiring authentication before any database access can be
+ performed, and checking access rights and authentication credentials
+ before releasing information. [CAP] uses the Simple Authentication
+ Security Layer (SASL) for this authentication. In iMIP [RFC-2447],
+ this may present some challenges, as authentication is often not a
+ consideration in store-and-forward protocols.
+
+
+
+
+
+Mahoney, et. al. Informational [Page 12]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+ Authentication is also important for scheduling, in that receivers of
+ scheduling messages should be able to validate the apparent sender.
+ Since scheduling messages are wrapped in MIME [RFC-2045], signing and
+ encryption are freely available. For messages transmitted over mail,
+ this is the only available alternative. It is suggested that
+ developers take care in implementing the security features in iMIP
+ [RFC-2447], bearing in mind that the concept and need may be foreign
+ or non-obvious to users, yet essential for the system to function as
+ they might expect.
+
+ The real-time protocols provide for the authentication of users, and
+ the preservation of that authentication information, allowing for
+ validation by the receiving end-user or server.
+
+6.3 Using E-mail
+
+ Because scheduling information can be transmitted over mail without
+ any authentication information, e-mail spoofing is extremely easy if
+ the receiver is not checking for authentication. It is suggested
+ that implementers consider requiring authentication as a default,
+ using mechanisms such as are described in Section 3 of iMIP [RFC-
+ 2447]. The use of e-mail, and the potential for anonymous
+ connections, means that 'calendar spam' is possible. Developers
+ should consider this threat when designing systems, particularly
+ those that allow for automated request processing.
+
+6.4 Other Issues
+
+ The current security context should be obvious to users. Because the
+ underlying mechanisms may not be clear to users, efforts to make
+ clear the current state in the UI should be made. One example of
+ this is the 'lock' icon used in some Web browsers during secure
+ connections.
+
+ With both iMIP [RFC-2447] and [CAP], the possibilities of Denial of
+ Service attacks must be considered. The ability to flood a calendar
+ system with bogus requests is likely to be exploited once these
+ systems become widely deployed, and detection and recovery methods
+ will need to be considered.
+
+Acknowledgments
+
+ Thanks to the following, who have participated in the development of
+ this document:
+
+ Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn,
+ Alan Davies, Robb Surridge.
+
+
+
+
+Mahoney, et. al. Informational [Page 13]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+References
+
+ [RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring and
+ Scheduling Core Object Specification - iCalendar", RFC
+ 2445, November 1998.
+
+ [RFC-2446] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
+ "iCalendar Transport-Independent Interoperability Protocol
+ (iTIP): Scheduling Events, Busy Time, To-dos and Journal
+ Entries", RFC 2446, November 1998.
+
+ [RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
+ Message-Based Interoperability Protocol - iMIP", RFC 2447,
+ November 1998.
+
+ [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) - Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [CAP] Mansour, S., Royer, D., Babics, G., and Hill, P.,
+ "Calendar Access Protocol (CAP)", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahoney, et. al. Informational [Page 14]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+Authors' Addresses
+
+ Bob Mahoney
+ MIT
+ E40-327
+ 77 Massachusetts Avenue
+ Cambridge, MA 02139
+ US
+
+ Phone: (617) 253-0774
+ EMail: bobmah@mit.edu
+
+
+ George Babics
+ Steltor
+ 2000 Peel Street
+ Montreal, Quebec H3A 2W5
+ CA
+
+ Phone: (514) 733-8500 x4201
+ EMail: georgeb@steltor.com
+
+
+ Alexander Taler
+
+ EMail: alex@0--0.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahoney, et. al. Informational [Page 15]
+
+RFC 3283 Guide to Internet Calendaring June 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). 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 implementation 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahoney, et. al. Informational [Page 16]
+