Network Working Group                           Andre Courtemanche, CS&T
Internet Draft - CAP Requirements                   Alec Dun,    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:                               November 21, 1997                                   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 (US East Coast), (Europe), (US West Coast), or (Pacific Rim).

Distribution of this document is unlimited.


The Calendar Access Protocol (CAP) protocol defines administrative, calendar management,
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

1. Introduction

   The requirements are broken into the following categories:

   . Model

   . Administration

   . Component Management

   Each of these is further broken down into requirements that a CAP
   implementation MUST support, and MAY support.  In some cases,
   functionality which is specifically excluded from CAP is listed in a

Courtemanche/Dun/Dawson/Mansour/O'Leary 1              Expires May 1998
   DOES NOT section.  Those items where further input from the working
   group is needed are listed in a NEEDS DISCUSSION section.

1.1 Assumptions

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

2.      Model


   1.      Support two connection models: (a) no data is stored on the client
     and (b) data The CAP protocol is stored on intended to support both the client connected and the server
synchronization operation.

1.2 Definitions

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

2.      Support a framework for authentication of a calendar user Scenarios

These are the usage scenarios used to drive the requirements list.
Understanding these scenarios and for
     one calendar user how they are useful to act as a designate 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 proxy for another user.

   3.      Support a framework for journal entry such that only the secure transport of data between creator
  can see all properties and others can see only the
     CUA start and end

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

   4. start and end times.

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

* Define a who can add items to their calendar address.

   5.      Specify the granularity store.

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

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

* Put requests for user A on calendar components.

   6.      Enforce user A's calendar, subject to access

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

   7.      Support capabilities negotiation to enable clients
  access control

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

* Perform any calendar operation on behalf of a CAP server.  Specify how a CUA queries a
     Calendar Store user A, subject to determine its attributes. access

2.2 Implementation Options

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

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

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

* A client wants to be notified by the server whenever any change is
  made to a given
     Calendar Store.

   8.      Return error codes particular calendar store.

* An alarm for valid commands a VEVENT or VTODO has gone off for a particular calendar

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 not supported by broken into the server.

   9.      Provide following categories:

* Basic

* Administration

* Component Management

There is some overlap between the capability categories.  All requirements in this
section are MUST HAVE features for the protocol draft to search, select, and operate 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
     stores based data on their properties. For example, both the client and
   the server, with some kind of synchronization.

3. Support a property framework for authentication of a calendar user

4. Allow one calendar user to act as a designate or proxy for another

5. Support the
     store might 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 its owner.


   1. returned for improper commands, unsupported
   commands, and command failures.

10. Allow Calendar Users users to search for calendar stores.

11. Allow calendar users to control the access that others have to
    their calendar.  Setting  See access that a group has to control scenarios above.

12. Allow a number of simple operations on calendar may stores to be supported.

   2.      Supports two types of transactions.  Type 1:
    grouped such that if the request any operation cannot be successfully completed on all
    calendar stores involved, don't
     do the operation at all.  Type 2: complete stores, then no change is made to any calendar store.

13. Support server-to-client notification.  See notification scenarios

14. Allow the operation on as
     many server implementation to return a referral when a request
    was made for a calendar stores as possible.  In either case, any failures or CU located elsewhere.  Servers must not be reported to the client.

Courtemanche/Dun/Dawson/Mansour/O'Leary 2              Expires May 1998
    required to make referrals.

15. Support server-to-client notification.  If functionality such that the server supports
     this capability, it must notify a client when is not forced to remain
    connected and waiting while a CAP event occurs command is in which progress. One possible way
    for the client has registered interest.

   4.      Supports server fan-out.  The fan-out capability can protocol to meet this requirement would be turned to allow the CU to
    abort a command that is taking too long.

16. Support properties on
     or off.

   5.      Provide calendar stores, including a standard
    property for user-defined rules.  Servers are not required a human-readable name.

3.2 Administration Requirements

In order to
     implement this functionality.

   6.      Provide for provide some interoperability of administration functions
on calendars, the archiving (import CAP protocol design must:

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

2. Allow creation and deletion of calendar stores.
     Servers are not required

3. Provide a way to implement archiving.

   7.      Provides for making referrals.  That is, supply the new address
     for set and change ownership of a user that is not calendar.

4. Support setting access control lists on this calendar system.  Servers a calendar.

5. Support retrieving access control lists from a calendar.

6. Enumerate the access levels that are not
     required to make referrals.

   8. possible on a calendar.

7. Support hierarchical functions to add, modify, and delete calendar stores.

   9.      Group names can be used properties.

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

3.3 Component Management Requirements

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

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

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

2. Allow users to create an invitation to an event or to-do.  Group names can be used to-do in setting access someone
   else's calendar store (subject to events and
     todos.  Servers are not required access control).

3. Allow users to explode retrieve the busy time on a group name into calendar store.

4. Allow the CUA to fetch a list of individuals.

   10.       Provide support for interrupting components based on a command in progress.

   11.       Provide query.  The
   query language must support the scenarios outlined above.

5. Allow a mechanism CUA to bound specify which properties will be returned in the latency
   results of a response.

   12.       Support the addition of functionality extensions. Commands on the
     wire fetch operation. The CUA should also be able invoke to get the extended functionality.  (This is
     something akin
   entire component (all properties).

6. Allow CUA to server plug-ins.)


   1.      Support fetch a set of alarms/reminders that are set to go off
   within a range of time.

7. Allow the CUA to register for fetching components and receive notifications from multiple Calendar Stores
     simultaneously.  (deferred)


   1.      Should more
   than one calendar and from more than one calendar server.

8. Allow the CUA to use the result of a CAP server provide any directory services or shall
     directory services query to perform modify,
   delete, and other operations.


9. The protocol will be supplied by an external capability. 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?

3.      Administration


  1.      Support connect and authenticate the CU.

Courtemanche/Dun/Dawson/Mansour/O'Leary 3              Expires May 1998
  2.      Create and delete calendar stores.

  3.      Set and change ownership of a calendar store.

4.      Support setting and retrieving access control lists Future Work

These are desirable areas for future work on calendars.
     Determine the access levels.

  5.      Support functions calendaring access.  In
order to add, modify, and delete calendar properties.

  6.      Return standardize the basic functionality for a handle to calendaring access
protocol in a calendar store based timely manner, these features will not be in the initial
CAP protocol.

1. Server fan-out.  The fan-out capability can be turned on a supplied calendar
     address and subject or off.
   Server fan-out is the ability for the server to access control.


  1.      List calendar stores subject automatically send
   meeting requests using [IRIP] or [IMIP] to access control.


  1.      Provide for server-to-server replication of calendar data.

4.      Component Management


   1.      Create, modify, and delete components those recipients in a calendar store.

   2.      Create or modify a set of component attributes.

   3.      Search for busy time
   meeting request.  With this functionality, the client creates the
   meeting request on a its calendar store.

   4.      Allow for Draft storage of components

   5.      Fetch components based on a query.  The query language must
     support (a) component property value comparisons and (b) component
     property parameter value comparisons.  The query language must
     support queries consisting the server takes care of multiple comparisons joined by
     boolean operators.

   6.      Return the results

2. User-defined rules.

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

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

4. Group names can be used to invite a Get filtered by a supplied list of

   7.      Read a set of alarms/reminders attendees to an event or
   to-do.  Group names can be used in a calendar that are set setting access to go
     off within events and
   to-dos.  Servers could explode a range group name into a list of time.



5. Support the expansion more complex types of transactions if a recurring event request cannot be
   completed successfully on all calendar stores involved.  For example,
   do not do the transaction at all or to-do.  If recurring
     expansion is supported, an error complete the operation on as many
   calendar stores as possible.  In either case, any failures must be returned for any problems
     that occur in
   reported to the expansion.

  2.      Notifications on multiple stores.

  3.      Modify, delete, and other? operations based client.

6. Support the addition of functionality extensions. Commands on a query.

Courtemanche/Dun/Dawson/Mansour/O'Leary 4              Expires May 1998
  4. 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



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

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

[ICAL] "Internet Calendaring and Scheduling Core Object Specification -
iCalendar", Internet-Draft, July 1997,

[ITIP] "iCalendar Transport-Independent Interoperability Protocol
(ITIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ",
Internet-Draft, October 1997,

[IMIP] "iCalendar Message-based Interoperability Protocol (IMIP),
Internet-Draft, October 1997,

[IRIP] "iCalendar Message-based Interoperability Protocol (IRIP),
Internet-Draft, October 1997,

7.      Author's 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

FN:Andre Courtemanche
ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R

FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613-

   FN:Alec Dun
FN:Tony Small
ORG:Microsoft Corporation
ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA;

FN:Steve Mansour

Courtemanche/Dun/Dawson/Mansour/O'Leary 5              Expires May 1998
ORG:Netscape Communications Corporation
ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain

FN:Peter O'Leary
ORG:Amplitude Software Corp.
ADR;WORK;POSTAL;PARCEL:;;185 Berry St. Suite 4700; San Francisco;CA;

Courtemanche/Dun/Dawson/Mansour/O'Leary 6

This work is part of the Internet Engineering Task Force Calendaring
and scheduling Working Group. The chairman of that working group is:

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 May 1998 Feb 1999   7