Network Working Group                           Andre Courtemanche, CS&T
Internet Draft - CAP Requirements    Tony Small, Lisa Lippert, Microsoft
<draft-ietf-calsch-capreq-01.txt>                    Frank Dawson, Lotus
                                                 Steve Mansour, Netscape
                                                 Pete O'Leary, Amplitude
Expires 6 months after:                                   August 6, 1998

CAP Requirements

Status of this Memo

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

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

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

Distribution of this document is unlimited.

Abstract

The Calendar Access Protocol (CAP) protocol defines calendar
administration and calendar component management on calendar stores by
owners, designates, and others. The purpose of this document is to set
forth a list requirements that CAP must address in order to address the
needs of the calendaring and scheduling community.























Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small   Expires Feb 1999   1


Internet Draft  CAP Requirements                          August 6, 1998


1. Introduction

1.1 Assumptions

1. The data elements of CAP are based on [ICAL].

2. The CAP protocol is intended to support both connected and
synchronization operation.

1.2 Definitions

The terms Calendar User (CU), Calendar User Agent (CUA), Calendar
Store, and Calendar Service (CS) are defined in [ICMS].

2. Scenarios

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.

2.1 Access Control

A user MUST be able to:

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

* Create an event or to-do such that only the attendees can see all
  properties and others can see only the start and end times.

* Create an event, to-do, or journal entry such that all properties can
  be seen by anyone.

* Define who can add items to their calendar store.

* Enable another person to act on behalf of the user.

* Fetch components from another user's calendar, subject to access
  control

* Put requests for user A on user A's calendar, subject to access
  control

* "Direct book" an event or to-do on user A's calendar, subject to
  access control

* Fetch user A's busy time, subject to access control

* Perform any calendar operation on behalf of user A, subject to access
  control.

2.2 Implementation Options

A server vendor may decide to only support VEVENT components and not
support VTODO and VJOURNAL components.  The client needs to query the
server to see which components are supported.

Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small   Expires Feb 1999   2


Internet Draft  CAP Requirements                          August 6, 1998


2.3 Notification

Server implementations may wish to allow clients to register for
events. When the event occurs, the server can notify the client.

The following notification scenarios MUST be supported by the protocol
design:

* A client wants to be notified by the server whenever any change is
  made to a particular calendar store.

* An alarm for a VEVENT or VTODO has gone off for a particular calendar
  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


Internet Draft  CAP Requirements                          August 6, 1998


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.

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.

16. Support properties on calendar stores, including a standard
    property for a human-readable name.

3.2 Administration Requirements

In order to provide some interoperability of administration functions
on calendars, the CAP protocol design must:

1. Allow a CUA to connect to the CAP server and authenticate the CU.

2. Allow creation and deletion of calendar stores.

3. Provide a way to set and change ownership of a calendar.

4. Support setting access control lists on a calendar.

5. Support retrieving access control lists from a calendar.

6. Enumerate the access levels that are possible on a calendar.

7. Support functions to add, modify, and delete calendar properties.

8. Allow users to list calendar stores (subject to access control).

3.3 Component Management Requirements


Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small   Expires Feb 1999   4


Internet Draft  CAP Requirements                          August 6, 1998

In order to provide interoperability of component management on
calendars, the CAP protocol design must:

1. Allow users to create, modify, and delete components in a calendar
   store.

2. Allow users to create an invitation to an event or to-do in someone
   else's calendar store (subject to access control).

3. Allow users to retrieve the busy time on a calendar store.

4. Allow the CUA to fetch a list of components based on a query.  The
   query language must support the scenarios outlined above.

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

6. Allow CUA to fetch a set of alarms/reminders that are set to go off
   within a range of time.

7. Allow the CUA to register for and receive notifications from more
   than one calendar and from more than one calendar server.

8. Allow the CUA to use the result of a query to perform modify,
   delete, and other operations.

Also,

9. The protocol will be designed such that a subset of component
   properties can be updated without having to specify all existing
   component properties.

10. The protocol draft must specify how and where (or how to tell
    where) expansion of recurring events will occur.

3.4 Open Issues

1. Given that access control to calendar stores must be addressed, is
   there a need to standardize the way Calendar Users are identified?

4. Future Work

These are desirable areas for future work on calendaring access.  In
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.

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.

2. User-defined rules.

3. Archiving (import and export) of calendar stores.


Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small   Expires Feb 1999   5


Internet Draft  CAP Requirements                          August 6, 1998

4. Group names can be used to invite a list of attendees to an event or
   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.

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

The following have provided input in the drafting of this memo:

    Mike Weston

6. Bibliography

[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,
Electronic Business Card, format.

Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small   Expires Feb 1999   6


Internet Draft  CAP Requirements                          August 6, 1998


BEGIN:VCARD
FN:Andre Courtemanche
ORG:CS&T
ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R
    3L5;Canada
TEL;WORK;MSG:+1-514-733-8500
TEL;WORK;FAX:+1-514-733-8788
EMAIL;INTERNET:andre@cst.ca
END:VCARD

BEGIN:VCARD
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;WORK;POSTAL;PARCEL:;;6544 Battleford
    Drive;Raleigh;NC;27613-3502;USA
TEL;WORK;MSG:+1-919-676-9515
TEL;WORK;FAX:+1-919-676-9564
EMAIL;INTERNET:Frank_Dawson@Lotus.com
URL:http://home.earthlink.net/~fdawson
END:VCARD

BEGIN:VCARD
FN:Tony Small
ORG:Microsoft Corporation
ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA;
    98052-6399;USA
TEL;WORK;MSG:+1-206-703-2190
TEL;WORK;FAX:+1-206-936-7329
EMAIL;INTERNET:tonysm@Microsoft.com
END:VCARD

BEGIN:VCARD
FN:Steve Mansour
ORG:Netscape Communications Corporation
ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain
    View;CA;94043;USA
TEL;WORK;MSG:+1-650-937-2378
TEL;WORK;FAX:+1-650-937-2103
EMAIL;INTERNET:sman@netscape.com
END:VCARD

BEGIN:VCARD
FN:Peter O'Leary
ORG:Amplitude Software Corp.
ADR;WORK;POSTAL;PARCEL:;;185 Berry St. Suite 4700; San Francisco;CA;
    94107;USA
TEL;WORK;MSG:+1-415-659-3511
TEL;WORK;FAX:+1-415-659-0006
EMAIL;INTERNET:poleary@amplitude.com
END:VCARD

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


Internet Draft  CAP Requirements                          August 6, 1998

    Livonia;MI;48152;USA
TEL;WORK;MSG:+1-734-542-5955
EMAIL;INTERNET:ganguly@acm.org
END:VCARD