draft-ietf-calsch-capreq-00.txt   draft-ietf-calsch-capreq-01.txt 
Network Working Group Andre Courtemanche, CS&T Network Working Group Andre Courtemanche, CS&T
Internet Draft - CAP Requirements Alec Dun, Microsoft Internet Draft - CAP Requirements Tony Small, Lisa Lippert, Microsoft
<draft-ietf-calsch-capreq-00.txt> Frank Dawson, Lotus <draft-ietf-calsch-capreq-01.txt> Frank Dawson, Lotus
Steve Mansour, Netscape Steve Mansour, Netscape
Pete O'Leary, Amplitude Pete O'Leary, Amplitude
Expires 6 months after: November 21, 1997 Expires 6 months after: August 6, 1998
CAP Requirements CAP Requirements
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas, and
and its working groups. Note that other groups may also distribute its working groups. Note that other groups may also distribute working
working documents as Internet-Drafts. documents as Internet-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. Internet-Drafts may be updated, replaced, or made obsolete Internet-Drafts may be updated, replaced, or made obsolete by other
by other documents at any time. It is not appropriate to use documents at any time. It is not appropriate to use Internet-Drafts as
Internet-Drafts as reference material or to cite them other than as a reference material or to cite them other than as a "working draft" or
"working draft" or "work in progress". "work in progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Rim).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Abstract Abstract
The Calendar Access Protocol (CAP) protocol defines administrative, The Calendar Access Protocol (CAP) protocol defines calendar
calendar management, and calendar component management on calendar administration and calendar component management on calendar stores by
stores by owners, designates, and others. The purpose of this owners, designates, and others. The purpose of this document is to set
document is to set forth a list requirements that CAP must address in forth a list requirements that CAP must address in order to address the
order to address the needs of the calendaring and scheduling needs of the calendaring and scheduling community.
community.
Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 1
1. Introduction 1. Introduction
The requirements are broken into the following categories: 1.1 Assumptions
. Model 1. The data elements of CAP are based on [ICAL].
. Administration 2. The CAP protocol is intended to support both connected and
synchronization operation.
. Component Management 1.2 Definitions
Each of these is further broken down into requirements that a CAP The terms Calendar User (CU), Calendar User Agent (CUA), Calendar
implementation MUST support, and MAY support. In some cases, Store, and Calendar Service (CS) are defined in [ICMS].
functionality which is specifically excluded from CAP is listed in a
Courtemanche/Dun/Dawson/Mansour/O'Leary 1 Expires May 1998 2. Scenarios
DOES NOT section. Those items where further input from the working
group is needed are listed in a NEEDS DISCUSSION section.
1.1 Assumptions These are the usage scenarios used to drive the requirements list.
Understanding these scenarios and how they are useful to clients and
administrators will help with understanding why these requirements were
chosen. However, these scenarios are not an exhaustive list.
1. The data elements of CAP are based on iCalendar. 2.1 Access Control
2. Model A user MUST be able to:
MUST * Create an event, to-do, or journal entry such that only the creator
can see all properties and others can see only the start and end
times.
1. Support two connection models: (a) no data is stored on the client * Create an event or to-do such that only the attendees can see all
and (b) data is stored on both the client and the server and is properties and others can see only the start and end times.
synchronized periodically.
2. Support a framework for authentication of a calendar user and for * Create an event, to-do, or journal entry such that all properties can
one calendar user to act as a designate or proxy for another user. be seen by anyone.
3. Support a framework for the secure transport of data between the * Define who can add items to their calendar store.
CUA and the CS.
4. Define a calendar address. * Enable another person to act on behalf of the user.
5. Specify the granularity of access control on calendar components. * Fetch components from another user's calendar, subject to access
control
6. Enforce access control to calendar components * Put requests for user A on user A's calendar, subject to access
control
7. Support capabilities negotiation to enable clients to determine * "Direct book" an event or to-do on user A's calendar, subject to
the capabilities of a CAP server. Specify how a CUA queries a access control
Calendar Store to determine its attributes. The client must be
able to determine which Components are supported by a given
Calendar Store.
8. Return error codes for valid commands that are not supported by * Fetch user A's busy time, subject to access control
the server.
9. Provide the capability to search, select, and operate on calendar * Perform any calendar operation on behalf of user A, subject to access
stores based on their properties. For example, a property of the control.
store might be its owner.
MAY 2.2 Implementation Options
1. Allow Calendar Users to control the access that others have to A server vendor may decide to only support VEVENT components and not
their calendar. Setting access that a group has to a calendar may support VTODO and VJOURNAL components. The client needs to query the
be supported. server to see which components are supported.
2. Supports two types of transactions. Type 1: if the request cannot Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 2
be successfully completed on all calendar stores involved, don't
do the operation at all. Type 2: complete the operation on as
many calendar stores as possible. In either case, any failures
must be reported to the client.
Courtemanche/Dun/Dawson/Mansour/O'Leary 2 Expires May 1998 2.3 Notification
3. Support server-to-client notification. If the server supports
this capability, it must notify a client when a CAP event occurs
in which the client has registered interest.
4. Supports server fan-out. The fan-out capability can be turned on Server implementations may wish to allow clients to register for
or off. events. When the event occurs, the server can notify the client.
5. Provide for user-defined rules. Servers are not required to The following notification scenarios MUST be supported by the protocol
implement this functionality. design:
6. Provide for the archiving (import and export) of calendar stores. * A client wants to be notified by the server whenever any change is
Servers are not required to implement archiving. made to a particular calendar store.
7. Provides for making referrals. That is, supply the new address * An alarm for a VEVENT or VTODO has gone off for a particular calendar
for a user that is not on this calendar system. Servers are not store.
2.4 Search Scenarios
The following searches MUST be supported in some manner.
* Search for all items of a certain type (e.g. VEVENT)
* Search for all items with a start time greater than x OR an end time
less than y.
* Search for all items of type VEVENT, with start and end types such
that the event overlaps a certain period (i.e. 24 hours of one day)
* Search for all items with a display name containing a string S
* Search for all items with an attendee list that contains the user S
3. Requirements
The requirements are broken into the following categories:
* Basic
* Administration
* Component Management
There is some overlap between the categories. All requirements in this
section are MUST HAVE features for the protocol draft to address.
3.1 Basic requirements
The CAP protocol design must:
1. Support the model of storing calendar data only on the server.
2. Support the model of storing calendar data on both the client and
the server, with some kind of synchronization.
3. Support a framework for authentication of a calendar user
4. Allow one calendar user to act as a designate or proxy for another
user.
5. Support the transport of encrypted data between the CUA and the CS.
Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 3
6. Define calendar addresses that support hierarchical names.
7. Specify the granularity of access control on calendars. See the
access control scenarios above.
8. Allow clients to determine what data components (i.e. VEVENT, VTODO)
a CAP server supports.
9. Define error codes to be returned for improper commands, unsupported
commands, and command failures.
10. Allow users to search for calendar stores.
11. Allow calendar users to control the access that others have to
their calendar. See access control scenarios above.
12. Allow a number of simple operations on calendar stores to be
grouped such that if any operation cannot be completed on all
calendar stores, then no change is made to any calendar store.
13. Support server-to-client notification. See notification scenarios
above.
14. Allow the server implementation to return a referral when a request
was made for a calendar or CU located elsewhere. Servers must not be
required to make referrals. required to make referrals.
8. Support hierarchical calendar stores. 15. Support functionality such that the client is not forced to remain
connected and waiting while a command is in progress. One possible way
for the protocol to meet this requirement would be to allow the CU to
abort a command that is taking too long.
9. Group names can be used to invite a list of attendees to an event 16. Support properties on calendar stores, including a standard
or to-do. Group names can be used in setting access to events and property for a human-readable name.
todos. Servers are not required to explode a group name into a
list of individuals.
10. Provide support for interrupting a command in progress. 3.2 Administration Requirements
11. Provide a mechanism to bound the latency of a response. In order to provide some interoperability of administration functions
on calendars, the CAP protocol design must:
12. Support the addition of functionality extensions. Commands on the 1. Allow a CUA to connect to the CAP server and authenticate the CU.
wire should be able invoke the extended functionality. (This is
something akin to server plug-ins.)
DOES NOT 2. Allow creation and deletion of calendar stores.
1. Support for fetching components from multiple Calendar Stores 3. Provide a way to set and change ownership of a calendar.
simultaneously. (deferred)
NEEDS DISCUSSION: 4. Support setting access control lists on a calendar.
1. Should a CAP server provide any directory services or shall 5. Support retrieving access control lists from a calendar.
directory services be supplied by an external capability. Given
that access control to calendar stores must be addressed, is there
a need to standardize the way Calendar Users are identified?
3. Administration 6. Enumerate the access levels that are possible on a calendar.
MUST 7. Support functions to add, modify, and delete calendar properties.
1. Support connect and authenticate the CU. 8. Allow users to list calendar stores (subject to access control).
Courtemanche/Dun/Dawson/Mansour/O'Leary 3 Expires May 1998 3.3 Component Management Requirements
2. Create and delete calendar stores.
3. Set and change ownership of a calendar store. Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 4
4. Support setting and retrieving access control lists on calendars. In order to provide interoperability of component management on
Determine the access levels. calendars, the CAP protocol design must:
5. Support functions to add, modify, and delete calendar properties. 1. Allow users to create, modify, and delete components in a calendar
store.
6. Return a handle to a calendar store based on a supplied calendar 2. Allow users to create an invitation to an event or to-do in someone
address and subject to access control. else's calendar store (subject to access control).
MAY 3. Allow users to retrieve the busy time on a calendar store.
1. List calendar stores subject to access control. 4. Allow the CUA to fetch a list of components based on a query. The
query language must support the scenarios outlined above.
DOES NOT 5. Allow a CUA to specify which properties will be returned in the
results of a fetch operation. The CUA should also be able to get the
entire component (all properties).
1. Provide for server-to-server replication of calendar data. 6. Allow CUA to fetch a set of alarms/reminders that are set to go off
within a range of time.
4. Component Management 7. Allow the CUA to register for and receive notifications from more
than one calendar and from more than one calendar server.
MUST 8. Allow the CUA to use the result of a query to perform modify,
delete, and other operations.
1. Create, modify, and delete components in a calendar store. Also,
2. Create or modify a set of component attributes. 9. The protocol will be designed such that a subset of component
properties can be updated without having to specify all existing
component properties.
3. Search for busy time on a calendar store. 10. The protocol draft must specify how and where (or how to tell
where) expansion of recurring events will occur.
4. Allow for Draft storage of components 3.4 Open Issues
5. Fetch components based on a query. The query language must 1. Given that access control to calendar stores must be addressed, is
support (a) component property value comparisons and (b) component there a need to standardize the way Calendar Users are identified?
property parameter value comparisons. The query language must
support queries consisting of multiple comparisons joined by
boolean operators.
6. Return the results of a Get filtered by a supplied list of 4. Future Work
attributes.
7. Read a set of alarms/reminders in a calendar that are set to go These are desirable areas for future work on calendaring access. In
off within a range of time. order to standardize the basic functionality for a calendaring access
protocol in a timely manner, these features will not be in the initial
CAP protocol.
MAY 1. Server fan-out. The fan-out capability can be turned on or off.
Server fan-out is the ability for the server to automatically send
meeting requests using [IRIP] or [IMIP] to those recipients in a
meeting request. With this functionality, the client creates the
meeting request on its calendar and the server takes care of the
rest.
1. Support the expansion of a recurring event or to-do. If recurring 2. User-defined rules.
expansion is supported, an error must be returned for any problems
that occur in the expansion.
2. Notifications on multiple stores. 3. Archiving (import and export) of calendar stores.
3. Modify, delete, and other? operations based on a query. Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 5
Courtemanche/Dun/Dawson/Mansour/O'Leary 4 Expires May 1998 4. Group names can be used to invite a list of attendees to an event or
4. Add, modify, or delete components based on a query of calendar to-do. Group names can be used in setting access to events and
to-dos. Servers could explode a group name into a list of
individuals.
5. Support more complex types of transactions if a request cannot be
completed successfully on all calendar stores involved. For example,
do not do the transaction at all or complete the operation on as many
calendar stores as possible. In either case, any failures must be
reported to the client.
6. Support the addition of functionality extensions. Commands on the
wire should be able invoke the extended functionality. (This is
something akin to server plug-ins.)
7. Allow for Draft storage of components
8. Add, modify, or delete components based on a query of calendar
stores. stores.
NEEDS DISCUSSION 9. Get components from multiple stores in a single command.
1. Get components from multiple stores in a single command. 10. The capability to list calendar stores based on properties.
11. The capability to perform an operation on a number of calendar
stores.
5. Acknowledgments 5. Acknowledgments
The following have provided input in the drafting of this memo: The following have provided input in the drafting of this memo:
Mike Weston Mike Weston
6. Bibliography 6. Bibliography
7. Author's Address [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July
1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt.
[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.
[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.
[IMIP] "iCalendar Message-based Interoperability Protocol (IMIP),
Internet-Draft, October 1997,
http://www.imc.org/draft-ietf-calsch-imip.
[IRIP] "iCalendar Message-based Interoperability Protocol (IRIP),
Internet-Draft, October 1997,
http://www.imc.org/draft-ietf-calsch-irip.
7. Authors' Address
The following address information is provided in a vCard v2.1, The following address information is provided in a vCard v2.1,
Electronic Business Card, format. Electronic Business Card, format.
Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 6
BEGIN:VCARD BEGIN:VCARD
FN:Andre Courtemanche FN:Andre Courtemanche
ORG:CS&T ORG:CS&T
ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R
3L5;Canada 3L5;Canada
TEL;WORK;MSG:+1-514-733-8500 TEL;WORK;MSG:+1-514-733-8500
TEL;WORK;FAX:+1-514-733-8788 TEL;WORK;FAX:+1-514-733-8788
EMAIL;INTERNET:andre@cst.ca EMAIL;INTERNET:andre@cst.ca
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
FN:Frank Dawson FN:Frank Dawson
ORG:Lotus Development Corporation ORG:Lotus Development Corporation
ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- ADR;WORK;POSTAL;PARCEL:;;6544 Battleford
3502;USA Drive;Raleigh;NC;27613-3502;USA
TEL;WORK;MSG:+1-919-676-9515 TEL;WORK;MSG:+1-919-676-9515
TEL;WORK;FAX:+1-919-676-9564 TEL;WORK;FAX:+1-919-676-9564
EMAIL;INTERNET:fdawson@earthlink.net EMAIL;INTERNET:Frank_Dawson@Lotus.com
URL:http://home.earthlink.net/~fdawson URL:http://home.earthlink.net/~fdawson
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
FN:Alec Dun FN:Tony Small
ORG:Microsoft Corporation ORG:Microsoft Corporation
ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA; ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA;
98052-6399;USA 98052-6399;USA
TEL;WORK;MSG:+1-206-936-4544 TEL;WORK;MSG:+1-206-703-2190
TEL;WORK;FAX:+1-206-936-7329 TEL;WORK;FAX:+1-206-936-7329
EMAIL;INTERNET:alecdu@Microsoft.com EMAIL;INTERNET:tonysm@Microsoft.com
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
FN:Steve Mansour FN:Steve Mansour
Courtemanche/Dun/Dawson/Mansour/O'Leary 5 Expires May 1998
ORG:Netscape Communications Corporation ORG:Netscape Communications Corporation
ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain
View;CA;94043;USA View;CA;94043;USA
TEL;WORK;MSG:+1-415-937-2378 TEL;WORK;MSG:+1-650-937-2378
TEL;WORK;FAX:+1-415-428-4059 TEL;WORK;FAX:+1-650-937-2103
EMAIL;INTERNET:sman@netscape.com EMAIL;INTERNET:sman@netscape.com
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
FN:Peter O'Leary FN:Peter O'Leary
ORG:Amplitude Software Corp. ORG:Amplitude Software Corp.
ADR;WORK;POSTAL;PARCEL:;;185 Berry St. Suite 4700; San Francisco;CA; ADR;WORK;POSTAL;PARCEL:;;185 Berry St. Suite 4700; San Francisco;CA;
94107;USA 94107;USA
TEL;WORK;MSG:+1-415-659-3511 TEL;WORK;MSG:+1-415-659-3511
TEL;WORK;FAX:+1-415-659-0006 TEL;WORK;FAX:+1-415-659-0006
EMAIL;INTERNET:poleary@amplitude.com EMAIL;INTERNET:poleary@amplitude.com
END:VCARD END:VCARD
Courtemanche/Dun/Dawson/Mansour/O'Leary 6 Expires May 1998 This work is part of the Internet Engineering Task Force Calendaring
and scheduling Working Group. The chairman of that working group is:
BEGIN:VCARD
FN:Anik Ganguly
ORG:Open Text, Inc.
ADR;WORK;POSTAL;PARCEL:;;38777 West Six Mile Road Suite 101;
Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 7
Livonia;MI;48152;USA
TEL;WORK;MSG:+1-734-542-5955
EMAIL;INTERNET:ganguly@acm.org
END:VCARD
 End of changes. 80 change blocks. 
144 lines changed or deleted 253 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/