draft-ietf-calsch-inetcal-guide-00.txt   draft-ietf-calsch-inetcal-guide-01.txt 
Network Working Group Bob Mahoney/MIT
Internet Draft George Babics/Steltor Network Working Group B. Mahoney
<draft-ietf-calsch-inetcal-guide-00.txt> Internet-Draft MIT
February 20 2001 Expires: August 20 2001 Expires: January 16, 2002 G. Babics
Steltor
A. Taler
July 18, 2001
Guide to Internet Calendaring Guide to Internet Calendaring
draft-ietf-calsch-inetcal-guide-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society 2000. All Rights Reserved. This Internet-Draft will expire on January 16, 2002.
Abstract
This document describes the various internet calendaring and Copyright Notice
scheduling standards and drafts and the relationships between them.
It's intention is to provide a context for these documents, assist
in their understanding, and potentially help implementors in the
design of their internet calendaring and scheduling systems. The
standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and
RFC 2447 (iMIP). The draft addressed is "Calendar Access Protocol"
(CAP).
[Note: in the past there has been some discussion as to whether iRIP Copyright (C) The Internet Society (2001). All Rights Reserved.
was a live effort, given that interest has waned and some
functionality has been moved to CAP. Its status will be discussed
further.]
This document also describes issues and problems that are not solved Abstract
by these protocols, and could be targets for future work.
Status of this Memo This document describes the various Internet calendaring and
scheduling standards and works in progress and the relationships
between them. It's intention is to provide a context for these
documents, assist in their understanding, and potentially help
implementers in the design of their 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 could be targets for future work.
1. Introduction Table of Contents
Terminology
2. Requirements
Fundamental Need
Protocol Requirements
3. Standards Solution
Examples
Systems
Standalone single-user system
Single-user systems communicating
4. Important Aspects
Mahoney/Babics 1 Expires August 2001 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
Timezones 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
Choice of Transport 1.2 Concepts and Relationships . . . . . . . . . . . . . . . . . 5
Security 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
Amount of data 2.1 Fundamental Needs . . . . . . . . . . . . . . . . . . . . . 6
Recurring Components 2.2 Protocol Requirements . . . . . . . . . . . . . . . . . . . 6
5. Open Issues 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 8
Choice of Transport 3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Scheduling People, not calendars 3.2 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Administration 3.2.1 Standalone single-user system . . . . . . . . . . . . . . . 9
Notification 3.2.2 Single-user systems communicating . . . . . . . . . . . . . 9
6. Security Considerations 3.2.3 Single-user with multiple CUA . . . . . . . . . . . . . . . 10
Access Control 3.2.4 Single-user with multiple calendars . . . . . . . . . . . . 10
Authentication 3.2.5 Users communicating on a multi-user system . . . . . . . . . 11
Using Email 3.2.6 Users communicating through different multi-user systems . . 11
Other issues 4. Important Aspects . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements 4.1 Timezones . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Bibliography 4.2 Choice of Transport . . . . . . . . . . . . . . . . . . . . 12
9. Author's Addresses 4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Full Copyright Statement 4.4 Amount of data . . . . . . . . . . . . . . . . . . . . . . . 12
4.5 Recurring Components . . . . . . . . . . . . . . . . . . . . 12
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 Scheduling people, not calendars . . . . . . . . . . . . . . 14
5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security considerations . . . . . . . . . . . . . . . . . . 15
6.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . 15
6.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 15
6.3 Using email . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4 Other issues . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
B. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The calendaring and scheduling protocols are intended to provide for The calendaring and scheduling protocols are intended to provide for
the needs of individuals attempting to obtain calendaring the needs of individuals attempting to obtain calendaring information
information and schedule meetings across the internet, organizations and schedule meetings across the Internet, organizations attempting
attempting to provide calendaring information on the internet, as to provide calendaring information on the Internet, as well as
well as organizations looking for a calendaring and scheduling organizations looking for a calendaring and scheduling solution to
solution to deploy internally. deploy internally.
It is the intent of this document is to provide a context for the It is the intent of this document to provide a context for the
calendar standard and draft documents, assist in their calendar standards and works in progress, assist in their
understanding, and potentially help implementors in the design of understanding, and potentially help implementers in the design of
their internet calendaring and scheduling systems. their Internet calendaring and scheduling systems.
Problems not solved by these protocols, as well as security issues Problems not solved by these protocols, as well as security issues to
to be kept in mind, are discussed at the end of the document. be kept in mind, are discussed at the end of the document.
1.1 Terminology 1.1 Terminology
This memo uses much of the same terminology as [ICAL], [ITIP], This memo uses much of the same terminology as iCalendar [RFC-2445],
[IMIP], [IRIP] and [CAP]. The following definitions are provided as iTIP [RFC-2446], iMIP [RFC-2447], and [CAP]. The following
introductory, the definitions in the protocol specifications are the definitions are provided as introductory, the definitions in the
canonical ones. protocol specifications are the canonical ones.
Calendar Calendar
A collection of events, todos, journal entries, etc. A
calendar could be the content of a person or a resource's A collection of events, to-dos, journal entries, etc. A calendar
agenda; it could also be a collection of data serving a more could be the content of a person or a resource's agenda; it could
specialized need. Calendars are the basic storage containers also be a collection of data serving a more specialized need.
for calendaring information. Calendars are the basic storage containers for calendaring
information.
Calendar Access Rights Calendar Access Rights
A set of rules for a calendar describing who may perform
which operations on that calendar, such as reading and A set of rules for a calendar describing who may perform which
writing information. operations on that calendar, such as reading and writing
information.
Calendar Service Calendar Service
A running server application which provides access to a
collection of calendars.
Calendar Store A running server application which provides access to a collection
A data store of a calendar service. A calendar service may of calendars.
Mahoney/Babics 2 Expires August 2001 Calendar Store (CS)
have several calendar stores, and each store may contain
several calendars, as well as properties and components
outside of the calendars.
Calendar User A data store of a calendar service. A calendar service may have
An entity (often a human) that accesses calendar several calendar stores, and each store may contain several
information. calendars, as well as properties and components outside of the
calendars.
Calendar User (CU)
An entity (often a human) that accesses calendar information.
Calendar User Agent (CUA) Calendar User Agent (CUA)
Software used by the calendar user that communicates with
calendar services to provide the user access to calendar Software used by the calendar user that communicates with calendar
information. services to provide the user access to calendar information.
Component Component
A piece of calendar data such as an event, a todo or an
alarm. Information about components is stored as properties
of those components.
Delegate 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
Is a calendar user (sometimes called the delegatee) who has Is a calendar user (sometimes called the delegatee) who has
been assigned participation in a scheduled calendar assigned his or her participation in a scheduled calendar
component (e.g., VEVENT) by one of the attendees in the component (e.g., VEVENT) to another calendar user (sometimes
scheduled calendar component (sometimes called the called the delegate or delegatee).
delegator). An example of a delegate is a team member told
to go to a particular meeting. Delegate
Is a calendar user (sometimes called the delegatee) who has been
assigned participation in a scheduled calendar component (e.g.,
VEVENT) by one of the attendees in the scheduled calendar
component (sometimes called the delegator). An example of a
delegate is a team member told to go to a particular meeting.
Designate Designate
Is a calendar user who is authorized to act on behalf of
another calendar user. An example of a designate is an Is a calendar user who is authorized to act on behalf of another
assistant. calendar user. An example of a designate is an assistant.
Local Store Local Store
A CS which is on the same platform as the CUA. A CS which is on the same platform as the CUA.
Property Property
A property of a component, such as a description or a start
time. A property of a component, such as a description or a start time.
Remote Store Remote Store
A CS which is not on the same platform as the CUA. A CS which is not on the same platform as the CUA.
1.2 Concepts and Relationships 1.2 Concepts and Relationships
iCalendar is the Language to be used in calendar events. iCalendar is the language used to describe calendar objects. iTIP is
iTIP is how you use the language. a way to use the language to do scheduling. iMIP is how to do iTIP
iMIP is further definition for use over email. with email. CAP is a way to use the language, to access a calendar
iRIP is the language used over a real-time transport store in real-time.
CAP is how to use the language, in real-time, to access a
calendar server
Another way to put it is as follows:
iCalendar are the words
iTIP is the grammar book or the "Rosetta Stone".
iMIP is "expressing it in email terminology" an
EMAIL dictionary
CAP/iRIP is "expressing it for use in a Real Time transport"
A comparison with email:
RFC822 in email: iRIP in Calendaring (scheduling not
booking)
POP/IMAP in email: CAP in calendaring
iMIP uses RFC822
Mahoney/Babics 3 Expires August 2001 The relationship between the calendaring protocols is similar to that
RFC822 is a wrapper for email: iTIP is a wrapper for between the email protocols. In those terms iCalendar is like RFC
calendaring objects 822, iTIP and iMIP are like SMTP, and CAP is like POP or IMAP.
2. Requirements 2. Requirements
2.1 Fundamental Needs 2.1 Fundamental Needs
The following examples illustrate people's and The following examples illustrate people's and organizations' basic
organizations' basic calendaring and scheduling needs: calendaring and scheduling needs:
a] A doctor wishes to keep track of all his appointments. a] A doctor wishes to keep track of all his appointments.
Need: Read and manipulate one's own calendar with only one Need: Read and manipulate one's own calendar with only one CUA.
CUA.
b] A busy musician wants to maintain her schedule on an b] A busy musician wants to maintain her schedule with different
internet-based agenda which she can access from anywhere. devices, such as with an Internet-based agenda or with a PDA.
Need: Read and manipulate one's own calendar. Need: Read and manipulate one's own calendar, possibly with
solutions from different vendors.
c] A software development team wishes to share agenda c] A software development team wishes to share agenda information
information by using a group scheduling product in order by using a group scheduling product in order to more effectively
to more effectively schedule their time. schedule their time.
Need: Share calendar information with users using the same Need: Share calendar information with users using the same
calendar service. calendar service.
d] A teacher wants his students to be able to book time d] A teacher wants his students to be able to schedule calendar
slot during his office hours. entries during his office hours.
Need: Schedule calendar events and todos with users using Need: Schedule calendar events, to-dos and journals with users
the same calendar service. using the same calendar service.
e] A movie theatre wants to publish its schedule so that e] A movie theater wants to publish its schedule so that
prospective customers can easily access it. prospective customers can easily access it.
Need: Share calendar information with users using other Need: Share calendar information with users using other calendar
calendar services, possibly from different vendors. services, possibly from different vendors.
f] A social club wants to be able to organize events more
effectively by booking time with its members.
Need: Schedule calendar events and todos with users using
other calendar services, possibly from different vendors.
2.2 Protocol requirements
The first four needs can be satisfied through proprietary solutions,
but the last two cannot. From these needs we can establish that
protocols are required for accessing information in a calendar
store, and for scheduling events and todos. In addition these
protocols require a data format for representing calendar
information.
These roles are filled by the following protocol requirements.
- [ICAL] is the data format
[ICAL] provides data format for representing calendar
information which the other protocols can use. [ICAL] can
Mahoney/Babics 4 Expires August 2001
also be used in other contexts such as a drag and drop
format or an export/import format.
All the other protocols depend on [ICAL], so all elements
of a standards-based calendaring and scheduling systems
will have to interpret [ICAL].
For example the following describes an event:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VEVENT
ORGANIZER;CN=Jane Doe:MAILTO:jane@bar.com
DTSTART:20000905T120000Z
SUMMARY:Lunch
DTEND:20000905T130000Z
ATTENDEE;CN=John Smith:MAILTO:john@foo.com
ATTENDEE;CN=Jane Doe:MAILTO:doe@bar.com
END:VEVENT
END:VCALENDAR
- [ITIP] is the scheduling protocol
[ITIP] describes the messages used to schedule calendar f] A social club wants to be able to schedule calendar entries
events. These messages are represented in [ICAL], and effectively with its members.
have semantics that include such things as being an
invitation to a meeting, an acceptance of an invitation
or the assignation of a task.
[ITIP] messages are used in the scheduling work flow, Need: Schedule calendar events and to-dos with users using other
where users exchange messages in order to organize things calendar services, possibly from different vendors.
such as events and todos. CUAs generate and interpret
[ITIP] messages at the direction of the calendar user.
With [ITIP] one can create, modify, delete, reply to, 2.2 Protocol Requirements
counter, and decline counters to, the various [ICAL]
components. Furthermore, one can also request the
freebusy time of other people.
For example, to invite a user to the above event, one can Some of the needs can be met with proprietary solutions (a, c, d),
send a message like this one: but others can not (b, e, f). From these needs we can establish that
protocols are required for accessing information in a calendar store,
and for scheduling calendar entries. In addition these protocols
require a data format for representing calendar information.
BEGIN:VCALENDAR These roles are filled by the following protocol specifications.
METHOD:REQUEST
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VEVENT
ORGANIZER;CN=Jane Doe:MAILTO:jane@bar.com
DTSTART:20000905T120000Z
SUMMARY:Lunch
DTEND:20000905T130000Z
ATTENDEE;CN=John Smith:MAILTO:john@foo.com
ATTENDEE;CN=Jane Doe:MAILTO:doe@bar.com
END:VEVENT
END:VCALENDAR
The user, John Smith, can send a reply using the - iCalendar [RFC-2445] is the data format
REPLY method.
Mahoney/Babics 5 Expires August 2001 iCalendar [RFC-2445] provides data format for representing
[ITIP] is transport-independent, but has two specified calendar information which the other protocols can use. iCalendar
transport bindings, [IMIP] is a binding to email and [RFC-2445] can also be used in other contexts such as a drag and
[IRIP] is a real-time binding. In addition [CAP] will drop format or an export/import format. All the other protocols
provide a second real-time binding of [ITIP], allowing depend on iCalendar [RFC-2445], so all elements of a standards-
CUAs to perform calendar management as well as scheduling based calendaring and scheduling systems will have to interpret
over a single connection. iCalendar [RFC-2445].
For example, sending the above request using iMIP would - iTIP [RFC-2446] is the scheduling protocol
look like:
From: jane@bar.com iTIP [RFC-2446] describes the messages used to schedule calendar
To: john@foo.com events. These messages are represented in iCalendar [RFC-2445],
Subject: Lunch and have semantics that include such things as being an invitation
Mime-Version: 1.0 to a meeting, an acceptance of an invitation or the assignment of
Content-Type:text/calendar; method=REQUEST;charset=US-ASCII a task.
Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR iTIP [RFC-2446] messages are used in the scheduling workflow,
VERSION:2.0 where users exchange messages in order to organize things such as
PRODID:-//ABC Corporation//NONSGML My Product//EN events and to-dos. CUAs generate and interpret iTIP [RFC-2446]
BEGIN:VEVENT messages at the direction of the calendar user. With iTIP [RFC-
ORGANIZER;CN=Jane Doe:MAILTO:jane@bar.com 2446] one can create, modify, delete, reply to, counter, and
DTSTART:20000905T120000Z decline counters to the various iCalendar [RFC-2445] components.
SUMMARY:Lunch Furthermore, one can also request the free/busy time of other
DTEND:20000905T130000Z people.
ATTENDEE;CN=John Smith:MAILTO:john@foo.com
ATTENDEE;CN=Jane Doe:MAILTO:doe@bar.com
END:VEVENT
END:VCALENDAR
Both CUAs and calendar services may have [ITIP] iTIP [RFC-2446] is transport-independent, and has one specified
interpreters. transport bindings: iMIP [RFC-2447] is a binding to email. In
addition [CAP] will provide a real-time binding of iTIP [RFC-
2446], allowing CUAs to perform calendar management as well as
scheduling over a single connection.
- [CAP] is the calendar management protocol - [CAP] is the calendar management protocol
[CAP] describes the messages used to manage calendars. These
messages are represented in [ICAL], and have semantics such as
being a search for data, being data in response to a search or
the being the creation of a meeting.
[CAP] describes the messages used to manage calendars on a [CAP] describes the messages used to manage calendars on a
calendar store. calendar store. These messages use iCalendar [RFC-2445] to
describe various components such as events and to-dos. With these
These messages are represented in [ICAL]. With these messages messages one can do the operations in iTIP [RFC-2446] and other
one can do the operations in [ITIP] and other operations operations relating to a calendar store, such as search, creating
relating to a calendar store. These operations include, calendars, specifying calendar properties, and being able to
search, creating calendars, specifying calendar properties, specify access rights to one's calendars.
and being able to specify access rights to one's calendars.
[CAP] also provides a real-time binding for the calendar
management messages. Although other bindings, such as an email
binding, could be defined, this is not done because it is
inappropriate for this protocol.
For example, one can schedule the above meeting using CAP:
C:SENDATA
C:CONTENT-TYPE:text/calendar;method=CREATE;charset=US-ASCII
C:content-transfer-encoding: 7bit
C:BEGIN:VCALENDAR
C:VERSION:2.0
Mahoney/Babics 6 Expires August 2001
C:PRODID:-//ABC Corporation//NONSGML My Product//EN
C:TARGET:cap://cal.example.com/johns
C:TARGET:janed
C:METHOD:CREATE
C:BEGIN:VEVENT
C:ORGANIZER;CN=Jane Doe:MAILTO:jane@bar.com
C:DTSTART:20000905T073000Z
C:SUMMARY:Lunch
C:DTEND:20000905T120000Z
C:END:VEVENT
C:END:VCALENDAR
C: .
S: 2.0
S: Content-Type:text/calendar; method=RESPONSE;
S:
S: BEGIN:VCALENDAR
S: VERSION:2.1
S: METHOD:RESPONSE
S: BEGIN:VEVENT
S: TARGET::cap://cal.example.com/johnd
S: REQUEST-STATUS:2.0
S: END:VEVENT
S: END:VCALENDAR
S: Content-Type:text/calendar; method=RESPONSE;
S:
S: BEGIN:VCALENDAR
S: VERSION:2.1
S: METHOD:RESPONSE
S: BEGIN:VEVENT
S: TARGET::cap://cal.example.com/janed
S: REQUEST-STATUS:2.0
S: END:VEVENT
S: END:VCALENDAR
S: .
Note that "C" indicates the data sent by the client,
and "S" the data sent by the server. Furthermore, CAP
is still a draft, thus the details of one can create
such an event may change.
The dependencies between the different protocols are as follows:
iCalendar is the language set used to describe/specify
calendaring events or operations.
When specified using correct iCalendar grammar, we refer to these
event representations or operation requests as " calendar object
representations
There are two main methodologies for communicating iCalendar
objects:
1) Via a store-and-forward mechanism (usually email), using the
iMIP specification.
2) Via an on-the-wire mechanism (a directly connected state,
however briefly), using the CAP specification.
A system may implement the first methodology only. The second one
is dependent on iTIP. It requires understanding of iTIP and the
ability to communicate with other CAP servers using iTIP. Since,
currently, iMIP is the only binding of iTIP, the second method
Mahoney/Babics 7 Expires August 2001
is also dependent on iMIP.
Additionally, the iTIP specification describes a
transport-independent grammar for communicating between systems.
The iMIP specification utilizes iTIP to express iCalendar
objects.
3. Solutions 3. Solutions
3.1 Examples 3.1 Examples
Returning to the examples of section 2.1, they can be solved Returning to the examples of section 2.1, they can be solved using
using the protocols in the following ways: the protocols in the following ways:
a] The doctor can use a proprietary CUA with a local store, a] The doctor can use a proprietary CUA with a local store, and
and perhaps use [ICAL] as a storage mechanism. This would perhaps use iCalendar [RFC-2445] as a storage mechanism. This
allow the doctor to easily import his store into another would allow the doctor to easily import his store into another
application that supports [ICAL]. application that supports iCalendar [RFC-2445].
b] The musician who wishes to access her agenda from anywhere b] The musician who wishes to access her agenda from anywhere can
can use a [CAP] enabled calendar service accessible through use a [CAP] enabled calendar service accessible through the
the internet. She can then use whichever [CAP] clients are Internet. She can then use whichever [CAP] clients are available
available to access the data. to access the data.
A proprietary system could also be employed which provides A proprietary system could also be employed which provides access
access through a web-based interface, but the use of [CAP] through a web-based interface, but the use of [CAP] would be
would be superior in that it would allow the use of third superior in that it would allow the use of third party tools, such
party tools, such as PDA synchronization tools. as PDA synchronization tools.
c] The development team can use a calendar service which c] The development team can use a calendar service which supports
supports [CAP] and then each member can use a [CAP]-enabled [CAP] and then each member can use a [CAP]-enabled CUA of their
CUA of their choice. choice.
Alternatively, each member could use an [IMIP]-enabled CUA, Alternatively, each member could use an iMIP [RFC-2447]-enabled
and they could book meetings over email. This solution has CUA, and they could book meetings over email. This solution has
the drawback that it is difficult to examine the other the drawback that it is difficult to examine the other agendas,
agendas, making organizing meetings more difficult. making organizing meetings more difficult.
Proprietary solutions are also available, but they require Proprietary solutions are also available, but they require that
that all people use clients by the same vendor, and all people use clients by the same vendor, and disallow the use of
disallow the use of third party applications. third party applications.
d] The teacher can set up a calendar service, and have d] The teacher can set up a calendar service, and have students
students book time through any of the [ITIP] bindings. book time through any of the iTIP [RFC-2446] bindings. [CAP]
[CAP] or [IRIP] provide real-time access, but could require provides real-time access, but could require additional
additional configuration. [IMIP] would be the easiest to configuration. iMIP [RFC-2447] would be the easiest to configure,
configure, but may require more email processing. but may require more email processing.
If [CAP] access is provided then determining the state of If [CAP] access is provided then determining the state of the
the teacher's schedule is straightforward. If not, this can teacher's schedule is straightforward. If not, this can be
be determined through [ITIP] free-busy requests. Non- determined through iTIP [RFC-2446] free/busy requests. Non-
standard methods could also be employed, such as serving up standard methods could also be employed, such as serving up ICAL,
ICAL, HTML, XML through HTTP. HTML, XML over HTTP.
A proprietary system could also be used, but would require A proprietary system could also be used, but would require that
that all students be able to use software from a specific all students be able to use software from a specific vendor.
vendor.
e] For publishing a movie theatre's schedule [CAP] provides e] For publishing a movie theater's schedule [CAP] provides the
the most advanced access and search capabilities. It also most advanced access and search capabilities. It also allows easy
allows easy integration with its customer's calendar integration with its customer's calendar systems.
Mahoney/Babics 8 Expires August 2001 Non-standard methods such as serving data over HTTP could also be
employed, but would be harder to integrate with customer's
systems. systems.
Non-standard methods such as serving data over HTTP could Using a completely proprietary solutions would be very difficult
also be employed, but would be harder to integrate with since it would require every user to install and use proprietary
customer's systems. software.
Using a completely proprietary solutions would be very
difficult since it would require every user to install and
use proprietary software.
f] The social club could distribute meeting information in the f] The social club could distribute meeting information in the
form of [ITIP] messages. This could be done over email form of iTIP [RFC-2446] messages. This could be done over email
using [IMIP], or [IRIP] depending on the recipient. Meeting using iMIP [RFC-2447]. Meeting invitations, as well as a full
invitations, as well as a full published agenda could be published agenda could be distributed.
distributed.
Alternatively, the social club could provide access to a Alternatively, the social club could provide access to a [CAP]
[CAP] enabled calendar service, however this solution would enabled calendar service, however this solution would be more
be more expensive since it requires the maintenance of a expensive since it requires the maintenance of a server.
server.
3.2 Systems 3.2 Systems
The following diagrams illustrate possible example systems and The following diagrams illustrate possible example systems and usage
usage of the protocols. of the protocols.
3.2.1 Standalone single-user system 3.2.1 Standalone single-user system
A single user system that does not communicate with other systems A single user system that does not communicate with other systems
need not employ any of the protocols. However, it may use [ICAL] as need not employ any of the protocols. However, it may use iCalendar
a data format in some places. [RFC-2445] as a data format in some places.
----------- O ----------- O
| CUA w/ | -+- user | CUA w/ | -+- user
|local store| A |local store| A
----------- / \ ----------- / \
3.2.2 Single-user systems communicating 3.2.2 Single-user systems communicating
Users with single-user systems may schedule meetings with each other Users with single-user systems may schedule meetings with each other
using [ITIP]. The easiest binding of [ITIP] to use is [IMIP], since using iTIP [RFC-2446]. The easiest binding of iTIP [RFC-2446] to use
it messages can be held in their mail queue, which we assume to is iMIP [RFC-2447], since since the messages can be held in their
already exist. [IRIP] or [CAP] would require at least one user to mail queue, which we assume to already exist. [CAP] could also be
run a listening server. used.
O ----------- ----------- O O ----------- ----------- O
-+- | CUA w/ | -----[IMIP]----- | CUA w/ | -+- user -+- | CUA w/ | -----[IMIP]----- | CUA w/ | -+- user
A |local store| Internet |local store| A A |local store| Internet |local store| A
/ \ ----------- ----------- / \ / \ ----------- ----------- / \
3.2.3 Single-user with multiple CUA 3.2.3 Single-user with multiple CUA
A single user may use more than one CUA to access his or her 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 calendar. The user may use a PDA, a web client, a PC, or some other
device, depending an accessibility. Some of these clients may have device, depending an accessibility. Some of these clients may have
local stores and others may not. If they do, then they need to local stores and others may not. If they do, then they need to
ensure that the data on the CUA is synchronized with the data on the ensure that the data on the CUA is synchronized with the data on the
CS. CS.
Mahoney/Babics 9 Expires August 2001
----------- -----------
| CUA w | -----[CAP]----------+ | CUA w | -----[CAP]----------+
|local store| | |local store| |
O ----------- ---------- O ----------- ----------
-+- | CS | -+- | CS |
A | | A | |
/ \ ---------- / \ ----------
----------- | ----------- |
| CUA w/o | -----[CAP]----------+ | CUA w/o | -----[CAP]----------+
|local store| |local store|
skipping to change at line 619 skipping to change at page 11, line 27
| | | |
---------- ----------
O ----------- | O ----------- |
-+- | CUA w/o | -----[CAP]----------+ -+- | CUA w/o | -----[CAP]----------+
A |local store| A |local store|
/ \ ----------- / \ -----------
3.2.6 Users communicating through different multi-user systems 3.2.6 Users communicating through different multi-user systems
Users on a multi-user system may need to schedule meetings with user Users on a multi-user system may need to schedule meetings with user
on a different multi user system. The services can communicate on a different multi user system. The services can communicate using
using [CAP] or [ITIP]. [CAP] or iMIP [RFC-2447].
Mahoney/Babics 10 Expires August
2001
O ----------- ---------- O ----------- ----------
-+- | CUA w | -----[CAP]-------| CS | -+- | CUA w | -----[CAP]-------| CS |
A |local store| | | A |local store| | |
/ \ ----------- ---------- / \ ----------- ----------
| |
[CAP] [CAP] or [iMIP]
| |
O ----------- ---------- O ----------- ----------
-+- | CUA w/o | -----[CAP]-------| CS | -+- | CUA w/o | -----[CAP]-------| CS |
A |local store| | | A |local store| | |
/ \ ----------- ---------- / \ ----------- ----------
4. Important Aspects 4. Important Aspects
There are a number of important aspects of these calendaring There are a number of important aspects of these calendaring
documents that people, especially implementors, should be aware of. documents of which people, especially implementers, should be aware.
4.1 Timezones 4.1 Timezones
The dates and times in components can refer to timezones. These The dates and times in components can refer to timezones. These
timezones can be defined in some central store, or they may be timezones can be defined in some central store, or they may be
defined by a user to fit his or her needs. Any user and application defined by a user to fit his or her needs. Any user and application
should be aware of timezones and timezone differences. should be aware of time zones and time zone differences. New time
zones may 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 4.2 Choice of Transport
There are issues to be aware of in choosing a transport mechanism. There are issues to be aware of in choosing a transport mechanism.
The choices are a network protocol, such as CAP, or a store and The choices are a network protocol, such as CAP, or a store and
forward (email) solution. forward (email) solution.
The use of a network ("on-the-wire") mechanism may require some The use of a network ("on-the-wire") mechanism may require some
organizations to make provisions to allow calendaring traffic to organizations to make provisions to allow calendaring traffic to
traverse a corporate firewall on the required ports. Depending on traverse a corporate firewall on the required ports. Depending on
the organizational culture, this may be a challenging social the organizational culture, this may be a challenging social
exercise. exercise.
The use of an email-based mechanism exposes innately time-sensitive The use of an email-based mechanism exposes innately time sensitive
data to unbounded latency. Large or heavily utilized mail systems data to unbounded latency. Large or heavily utilized mail systems
may experience an unacceptable delay in message receipt. may experience an unacceptable delay in message receipt.
4.3 Security 4.3 Security
See the "Security Considerations" section below. See the "Security Considerations" (Section 6) section below.
4.4 Amount of data 4.4 Amount of data
In some cases a component may be very large. For instance, some In some cases a component may be very large. For instance, some
attachments may be very large. Some applications may be low- attachments may be very large. Some applications may be low-
bandwidth or be limited in the amount of data they can store. The bandwidth or be limited in the amount of data they can store. The
size of the data may be controlled in [CAP], by specifying maximums. size of the data may be controlled in [CAP], by specifying maximums.
In [iMIP] it can be controlled, by restricting the maximum size of In iMIP [RFC-2447] it can be controlled, by restricting the maximum
the email that the application can download. size of the email that the application can download.
4.5 Recurring Components 4.5 Recurring Components
Mahoney/Babics 11 Expires August In iCAL [RFC-2445] one can specify complex recurrence rules for
2001 VEVENTs, VTODOs, and VJOURNALs. There is the danger that
In [iCAL] one can specify complex recurrence rules for VEVENTs, applications interpret these rules differently. Thus, one must make
VTODOs, and VJOURNALs. There is the danger that applications sure that one is careful with recurrence rules.
interpret these rules differently. Thus, one must make sure that one
is careful with recurrence rules.
5. Open Issues 5. Open Issues
Many issues are not currently resolved by these protocols, and many Many issues are not currently resolved by these protocols, and many
desirable features are not yet provided. Some of the more prominent desirable features are not yet provided. Some of the more prominent
ones follow. ones follow.
5.1 Scheduling people, not calendars 5.1 Scheduling people, not calendars
Meetings are scheduled with people, however people may have many Meetings are scheduled with people, however people may have many
skipping to change at line 725 skipping to change at page 15, line 11
client-side notification of upcoming events. To organize client-side notification of upcoming events. To organize
notification of new or changed events clients will have to poll the notification of new or changed events clients will have to poll the
data store. data store.
6. Security considerations 6. Security considerations
6.1 Access Control 6.1 Access Control
There has to be reasonable granularity in the configuration options There has to be reasonable granularity in the configuration options
for access to data through [CAP], so that what should be released to for access to data through [CAP], so that what should be released to
requestors is, and what shouldn't isn't. Details of handling this requesters is released, and what shouldn't isn't. Details of
are described in [CAP]. handling this are described in [CAP].
6.2 Authentication 6.2 Authentication
Access control must be coupled with a good authentication system, so Access control must be coupled with a good authentication system, so
that the right people get the right information. For [CAP] this that the right people get the right information. For [CAP] this
means requiring authentication before any data base access can be means requiring authentication before any data base access can be
performed, and checking access rights and authentication credentials performed, and checking access rights and authentication credentials
before releasing information. [CAP] uses SASL for this before releasing information. [CAP] uses SASL for this
authentication. In [IMIP], this may present some challenges, as authentication. In iMIP [RFC-2447], this may present some
authentication is often not a consideration in store-and-forward challenges, as authentication is often not a consideration in store-
protocols. and-forward protocols.
Authentication is also important for scheduling, in that receivers
of scheduling messages should be able to validate the apparent
Mahoney/Babics 12 Expires August Authentication is also important for scheduling, in that receivers of
2001 scheduling messages should be able to validate the apparent sender.
sender. Since scheduling messages are wrapped in MIME, signing and Since scheduling messages are wrapped in MIME [RFC-2045], signing and
encryption is available for free. For messages transmitted over mail encryption is available for free. For messages transmitted over mail
this is the only available alternative. It is suggested that this is the only available alternative. It is suggested that
developers take care in implementing the security features in developers take care in implementing the security features in iMIP
[IMIP], bearing in mind that the concept and need may be foreign or [RFC-2447], bearing in mind that the concept and need may be foreign
non-obvious to users, yet essential for the system to function as or non-obvious to users, yet essential for the system to function as
they might expect. they might expect.
The real-time protocols provide for the authentication of users, and The real-time protocols provide for the authentication of users, and
the preservation of that authentication information, allowing for the preservation of that authentication information, allowing for
validation by the receiving end-user or server. validation by the receiving end-user or server.
6.3 Using email 6.3 Using email
Because scheduling information can be transmitted over mail without Because scheduling information can be transmitted over mail without
any authentication information, email spoofing is extremely easy if any authentication information, email spoofing is extremely easy if
the receiver is not checking for authentication. It is suggested the receiver is not checking for authentication. It is suggested
that implementors consider requiring authentication as a default, that implementers consider requiring authentication as a default,
using mechanisms such as are described in Section 2 of [IMIP]. using mechanisms such as are described in Section 3 of iMIP [RFC-
2447]. The use of email, and the potential for anonymous
The use of email, and the potential for anonymous connections, means connections, means that 'calendar spam' is possible. Developers
that 'calendar spam' is possible. Developers should consider this should consider this threat when designing systems, particularly
threat when designing systems, particularly those that allow for those that allow for automated request processing.
automated request processing.
6.4 Other issues 6.4 Other issues
The current security context should be obvious to users. Because the The current security context should be obvious to users. Because the
underlying mechanisms may not be clear to users, efforts to make underlying mechanisms may not be clear to users, efforts to make
clear the current state in the UI should be made. One example is the clear the current state in the UI should be made. One example is the
'lock' icon used in some web browsers during secure connections. '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.
With both [IMIP] and [CAP], the possibilities of Denial of Service Authors' Addresses
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.
7. Acknowledgements 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
Alex Taler
EMail: dissent@elea.dhs.org
Appendix A. Acknowledgments
Thanks to the following who have participated in the development of Thanks to the following who have participated in the development of
this document: this document:
Eric Busboom, Alex Taler, Pat Egen, David Madeo, Shawn Packwood, Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn.
Bruce Kahn.
8. Bibliography Appendix B. Bibliography
[ICAL] [RFC-2445] Calendaring and Scheduling Core Object [RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring
Specification and Scheduling Core Object Specification - iCalendar", RFC 2445,
[ITIP] [RFC-2446] iCalendar Transport-Independent Interoperability November 1998.
Protocol
[IMIP] [RFC-2447] iCalendar Message-Based Interoperability Protocol
[IRIP] draft-ietf-calsch-irip iCalendar Real-time Interoperability
Protocol
[CAP] draft-ietf-calsch-cap Calendar Access Protocol
[RFC-1847] Security Multiparts for MIME [RFC-2446] Silverberg, S., Mansour, S., Dawson, F. and R.
[RFC-2045] MIME Part 1: Format of Internet Message Bodies Hopson, "iCalendar Transport-Independent Interoperability Protocol
[RFC-2046] MIME Part 2: Media Types (iTIP): Scheduling Events, Busy Time, To-dos and Journal Entries",
[RFC 2047] MIME Part 3: Message Header Extensions for Non-ASCII Text RFC 2446, November 1998.
Mahoney/Babics 13 Expires August [RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
2001 Message-Based Interoperability Protocol - iMIP", RFC 2447,
[RFC-2048] MIME Part 4: Registration Procedures November 1998.
[RFC-2049] MIME Part 5: Conformance Criteria and Examples
9. Author's Addresses [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) - Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
Bob Mahoney [CAP] Mansour, S., Royer, D., Babics, G., and Hill, P. "Calendar
MIT Access Protocol (CAP)" draft-ietf-calsch-cap-04.txt
E40-327
77 Massachusetts Avenue
Cambridge, MA 02139
Tel: (617) 253-0774
Email: bobmah@mit.edu
George Babics Full Copyright Statement
Steltor (formerly CS&T/Lexacom)
2000 Peel Street
Montreal, Quebec, Canada
H3A 2W5
Tel: (514) 733-8500 x4201
Fax: (514) 733-8878
mailto: georgeb@steltor.co m
10. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved.
"Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process MUST be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This revoked by the Internet Society or its successors or assigns.
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK This document and the information contained herein is provided on an
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 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. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Mahoney/Babics 14 Expires August Acknowledgement
2001
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 103 change blocks. 
505 lines changed or deleted 342 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/