One document matched: draft-ietf-calsch-capreq-00.txt

Network Working Group                          Andre Courtemanche, CS&T
Internet Draft - CAP Requirements                   Alec Dun, Microsoft
<draft-ietf-calsch-capreq-00.txt>                  Frank Dawson, Lotus
                                                Steve Mansour, Netscape
                                                Pete O'Leary, Amplitude
Expires 6 months after:                               November 21, 1997



                            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 ds.internic.net (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 administrative,
   calendar management, 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.

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



Internet Draft              CAP Requirements          November 21, 1997


   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.

2.      Model

   MUST

   1. 
     Support two connection models: (a) no data is stored on the client
     and (b) data is stored on both the client and the server and is
     synchronized periodically.

   2. 
     Support a framework for authentication of a calendar user and for
     one calendar user to act as a designate or proxy for another user.

   3. 
     Support a framework for the secure transport of data between the
     CUA and the CS.

   4. 
     Define a calendar address. 

   5. 
     Specify the granularity of access control on calendar components.

   6. 
     Enforce access control to calendar components

   7. 
     Support capabilities negotiation to enable clients to determine
     the capabilities of a CAP server.  Specify how a CUA queries a
     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
     the server.

   9. 
     Provide the capability to search, select, and operate on calendar
     stores based on their properties. For example, a property of the
     store might be its owner.

   MAY

   1. 
     Allow Calendar Users to control the access that others have to
     their calendar.  Setting access that a group has to a calendar may
     be supported.

   2. 
     Supports two types of transactions.  Type 1: if the request cannot
     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



Internet Draft              CAP Requirements          November 21, 1997


   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
     or off.

   5. 
     Provide for user-defined rules.  Servers are not required to
     implement this functionality.

   6. 
     Provide for the archiving (import and export) of calendar stores. 
     Servers are not required to implement archiving.

   7. 
     Provides for making referrals.  That is, supply the new address
     for a user that is not on this calendar system.  Servers are not
     required to make referrals.

   8. 
     Support hierarchical calendar stores.

   9. 
     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
     todos.  Servers are not required to explode a group name into a
     list of individuals.

   10. 
      Provide support for interrupting a command in progress.

   11. 
      Provide a mechanism to bound the latency of a response.

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


   DOES NOT

   1. 
     Support for fetching components from multiple Calendar Stores
     simultaneously.  (deferred)



   NEEDS DISCUSSION:

   1. 
     Should a CAP server provide any directory services or shall
     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

   MUST

  1. 
     Support connect and authenticate the CU.


Courtemanche/Dun/Dawson/Mansour/O'Leary 3              Expires May 1998



Internet Draft              CAP Requirements          November 21, 1997


  2. 
     Create and delete calendar stores.

  3. 
     Set and change ownership of a calendar store.

  4. 
     Support setting and retrieving access control lists on calendars.
     Determine the access levels.

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

  6. 
     Return a handle to a calendar store based on a supplied calendar
     address and subject to access control.

  MAY

  1. 
     List calendar stores subject to access control.

  DOES NOT

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

4.      Component Management

   MUST

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

   2. 
     Create or modify a set of component attributes.

   3. 
     Search for busy time on a 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 of multiple comparisons joined by
     boolean operators.

   6. 
     Return the results of a Get filtered by a supplied list of
     attributes.

   7. 
     Read a set of alarms/reminders in a calendar that are set to go
     off within a range of time.

   MAY

  1. 
     Support the expansion of a recurring event or to-do.  If recurring
     expansion is supported, an error must be returned for any problems
     that occur in the expansion.

  2. 
     Notifications on multiple stores.

  3. 
     Modify, delete, and other? operations based on a query.



Courtemanche/Dun/Dawson/Mansour/O'Leary 4              Expires May 1998



Internet Draft              CAP Requirements          November 21, 1997


  4. 
     Add, modify, or delete components based on a query of calendar
     stores.

   NEEDS DISCUSSION

   1. 
     Get components from multiple stores in a single command.

5.      Acknowledgments

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

   Mike Weston

6.      Bibliography

7.      Author's Address

   The following address information is provided in a vCard v2.1,
   Electronic Business Card, format.


   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:fdawson@earthlink.net
   URL:http://home.earthlink.net/~fdawson
   END:VCARD

   BEGIN:VCARD
   FN:Alec Dun
   ORG:Microsoft Corporation
   ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA;
   98052-6399;USA
   TEL;WORK;MSG:+1-206-936-4544
   TEL;WORK;FAX:+1-206-936-7329
   EMAIL;INTERNET:alecdu@Microsoft.com
   END:VCARD

   BEGIN:VCARD
   FN:Steve Mansour


Courtemanche/Dun/Dawson/Mansour/O'Leary 5              Expires May 1998



Internet Draft              CAP Requirements          November 21, 1997


   ORG:Netscape Communications Corporation
   ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain
   View;CA;94043;USA
   TEL;WORK;MSG:+1-415-937-2378
   TEL;WORK;FAX:+1-415-428-4059
   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







































Courtemanche/Dun/Dawson/Mansour/O'Leary 6              Expires May 1998