draft-ietf-calsch-capreq-02.txt   draft-ietf-calsch-capreq-03.txt 
Network Working Group Andre Courtemanche, CS&T Network Working Group Andre Courtemanche, CS&T
Internet Draft Frank Dawson, Lotus Internet Draft Frank Dawson, Lotus
<draft-ietf-calsch-capreq-02.txt> Steve Mansour, Netscape <draft-ietf-calsch-capreq-03.txt> Steve Mansour, Netscape
Pete O'Leary, Amplitude Pete O'Leary, Amplitude
Doug Royer, Sun Microsystems Doug Royer, Sun Microsystems
Tony Small, Microsoft Tony Small, Microsoft
Expires six months after: November 18, 1998 Expires six months after: May 27, 1999
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 and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026.
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 Internet-Drafts are working documents of the Internet Engineering
months. Internet-Drafts may be updated, replaced, or made obsolete by Task Force (IETF), its areas, and its working groups. Note that
other documents at any time. It is not appropriate to use Internet- other groups may also distribute working documents as
Drafts as reference material or to cite them other than as a "working Internet-Drafts.
draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the Internet-Drafts are draft documents valid for a maximum of six months
1id-abstracts.txt listing contained in the Internet-Drafts Shadow and may be updated, replaced, or obsoleted by other documents at any
Directories on ftp.ietf.org (US East Coast), nic.nordu.net time. It is inappropriate to use Internet- Drafts as reference
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific material or to cite them other than as "work in progress."
Rim).
Distribution of this document is unlimited. The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
The Calendar Access Protocol (CAP) is an Internet protocol for The Calendar Access Protocol (CAP) is an Internet protocol for
accessing an [ICAL] based calendar store (CS) from a calendar user accessing an [ICAL] based calendar store (CS) from a calendar user
agent (CUA). The purpose of this document is to set forth a list of agent (CUA). The purpose of this document is to set forth a list of
requirements that CAP MUST address in order to meet the needs of the requirements that CAP MUST address in order to meet the needs of the
calendaring and scheduling community. calendaring and scheduling community.
This document is based on discussions within the Internet Engineering This document is based on discussions within the Internet Engineering
skipping to change at line 59 skipping to change at line 58
Distribution of this document is unlimited. Comments and suggestions Distribution of this document is unlimited. Comments and suggestions
for improvement should be sent to the authors. for improvement should be sent to the authors.
Copyright (C) The Internet Society 1998. All Rights Reserved. Copyright (C) The Internet Society 1998. All Rights Reserved.
Change History Change History
Version 00 - Initial draft. Version 00 - Initial draft.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
1 Expires May 1998 1 Expires November 1999
Version 01 - Revised format; Included initial set of scenarios and Version 01 - Revised format; Included initial set of scenarios and
requirements. requirements.
Version 02 - Revised format; Significant modification to set of Version 02 - Revised format; Significant modification to set of
requirements. Included lists of requirements that are deferred to requirements. Included lists of requirements that are deferred to
later versions of CAP or to other drafts. later versions of CAP or to other drafts.
Version 03 - Repost of version 02.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
2 Expires May 1998 2 Expires November 1999
Table of Contents Table of Contents
1. Introduction........................................................4 1. Introduction........................................................4
2. Terminology.........................................................4 2. Terminology.........................................................4
3. Relationship To iCalendar, iTIP and iMIP/iRIP.......................7 3. Relationship To iCalendar, iTIP and iMIP/iRIP.......................7
4. Requirements........................................................7 4. Requirements........................................................7
4.1 Basic Usage ......................................................7 4.1 Basic Usage ......................................................7
4.2 Infrastructure ...................................................8 4.2 Infrastructure ...................................................8
4.2.1 Connection Models .............................................8 4.2.1 Connection Models .............................................8
4.2.2 Store Location Models .........................................9 4.2.2 Store Location Models .........................................9
skipping to change at line 106 skipping to change at line 107
4.9 Access Control (deferred) .......................................19 4.9 Access Control (deferred) .......................................19
4.10 Resource Groups and Pools (deferred) ...........................20 4.10 Resource Groups and Pools (deferred) ...........................20
4.11 CAP Non-requirements ...........................................21 4.11 CAP Non-requirements ...........................................21
5. Open Issues........................................................21 5. Open Issues........................................................21
6. Acknowledgments....................................................22 6. Acknowledgments....................................................22
7. Bibliography.......................................................22 7. Bibliography.......................................................22
8. Authors' Address...................................................22 8. Authors' Address...................................................22
9. Full Copyright Statement...........................................24 9. Full Copyright Statement...........................................24
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
3 Expires May 1998 3 Expires November 1999
1. Introduction 1. Introduction
The Calendar Access Protocol (CAP) is an Internet protocol for The Calendar Access Protocol (CAP) is an Internet protocol for
accessing an [ICAL] based calendar store (CS) from a calendar user accessing an [ICAL] based calendar store (CS) from a calendar user
agent (CUA). The purpose of this document is to set forth a list of agent (CUA). The purpose of this document is to set forth a list of
requirements that CAP MUST address in order to meet the needs of the requirements that CAP MUST address in order to meet the needs of the
calendaring and scheduling community. calendaring and scheduling community.
2. Terminology 2. Terminology
skipping to change at line 160 skipping to change at line 161
VEVENT, VTODO, VJOURNAL calendar components. Other calendar VEVENT, VTODO, VJOURNAL calendar components. Other calendar
components are applicable only to an individual type of calendar components are applicable only to an individual type of calendar
component. For example, TZURL is only applicable to VTIMEZONE component. For example, TZURL is only applicable to VTIMEZONE
calendar components. calendar components.
Calendar Identifier Calendar Identifier
Also known as "CalID". A globally unique identifier associated Also known as "CalID". A globally unique identifier associated
with a calendar within a CS. with a calendar within a CS.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
4 Expires May 1998 4 Expires November 1999
Calendar Policy Calendar Policy
An operational restriction on the access or manipulation of a An operational restriction on the access or manipulation of a
calendar. For example, "events MUST be scheduled in unit calendar. For example, "events MUST be scheduled in unit
intervals of one hour". intervals of one hour".
Calendar Properties Calendar Properties
An attribute of a calendar. The attibute applies to the calendar, An attribute of a calendar. The attibute applies to the calendar,
as a whole. For example, CALSCALE specifies the calendar scale as a whole. For example, CALSCALE specifies the calendar scale
(e.g., GREGORIAN) for the whole calendar. (e.g., GREGORIAN) for the whole calendar.
skipping to change at line 217 skipping to change at line 218
the calendar store. the calendar store.
Delegate Delegate
Is a calendar user (sometimes called the delegatee) who has been Is a calendar user (sometimes called the delegatee) who has been
assigned participation in a scheduled calendar component (e.g., assigned participation in a scheduled calendar component (e.g.,
VEVENT) by one of the attendees in the scheduled calendar VEVENT) by one of the attendees in the scheduled calendar
component (sometimes called the delegator). An example of a component (sometimes called the delegator). An example of a
delegate is a team member told to go to a particular meeting. delegate is a team member told to go to a particular meeting.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
5 Expires May 1998 5 Expires November 1999
Designate Designate
Is a calendar user who is authorized to act on behalf of another Is a calendar user who is authorized to act on behalf of another
calendar user. An example of a designate is an assistant. calendar user. An example of a designate is an assistant.
Disconnected Mode Disconnected Mode
A mobile computing mode where a CUA can be disconnected from a A mobile computing mode where a CUA can be disconnected from a
calendar store. When the CUA is disconnected, it is in the calendar store. When the CUA is disconnected, it is in the
disconnected mode. disconnected mode.
Fan Out Fan Out
skipping to change at line 272 skipping to change at line 273
Also known as "Qualified CalID". A complete Internet identifier Also known as "Qualified CalID". A complete Internet identifier
for a specific calendar. A Qualified CalID consists of a CAP for a specific calendar. A Qualified CalID consists of a CAP
specific "scheme" and "scheme part" portion of a URL, as defined specific "scheme" and "scheme part" portion of a URL, as defined
in [RFC1738]. A Qualified CalID are written only with the graphic in [RFC1738]. A Qualified CalID are written only with the graphic
printable characters of the US-ASCII coded character set. printable characters of the US-ASCII coded character set.
Remote Store Remote Store
A store which is not on the same hardware as the CUA. A store which is not on the same hardware as the CUA.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
6 Expires May 1998 6 Expires November 1999
Sub-calendars Sub-calendars
Calendars that are contained within other calendars in a Calendars that are contained within other calendars in a
hierarchical relationship. hierarchical relationship.
3. Relationship To iCalendar, iTIP and iMIP/iRIP 3. Relationship To iCalendar, iTIP and iMIP/iRIP
The CAP data elements MUST be based on the calendar architecture set The CAP data elements MUST be based on the calendar architecture set
forth in [ICAL]. More precisely, CAP will define an Internet protocol forth in [ICAL]. More precisely, CAP will define an Internet protocol
for accessing a CS that consists of one or more calendars, each for accessing a CS that consists of one or more calendars, each
consisting of numerous [ICAL] components. The definition of CAP might consisting of numerous [ICAL] components. The definition of CAP might
skipping to change at line 329 skipping to change at line 330
multiple calendars. multiple calendars.
- How to allow for a rich featured CUA. - How to allow for a rich featured CUA.
For example, allow a CUA to be part of a client which offers For example, allow a CUA to be part of a client which offers
rich calendaring, scheduling and related functionality, with the rich calendaring, scheduling and related functionality, with the
possibility of extending from concepts and services offered by possibility of extending from concepts and services offered by
CAP, while still using CAP to access a calendar. CAP, while still using CAP to access a calendar.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
7 Expires May 1998 7 Expires November 1999
- How to extend the base features in CAP. - How to extend the base features in CAP.
- How to allow for interpersonal applications to be calendar - How to allow for interpersonal applications to be calendar
enabled. enabled.
For example, a chat application MUST be able to offer a calendar For example, a chat application MUST be able to offer a calendar
button to create an event between the two or more parties. button to create an event between the two or more parties.
- How to allow for non-interpersonal applications to be calendar - How to allow for non-interpersonal applications to be calendar
enabled. enabled.
skipping to change at line 386 skipping to change at line 387
CUAs and CSs often support the "connected model", where clients CUAs and CSs often support the "connected model", where clients
maintain long-term connections to servers. Because of this, CAP MUST maintain long-term connections to servers. Because of this, CAP MUST
specify how the connection between a CUA and a CS can be maintained. specify how the connection between a CUA and a CS can be maintained.
CAP MUST NOT prevent servers from dropping client connections, CAP MUST NOT prevent servers from dropping client connections,
particularly idle client connections. CAP MUST provide some ways for particularly idle client connections. CAP MUST provide some ways for
clients to indicate that they would like to stay connected, or that clients to indicate that they would like to stay connected, or that
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
8 Expires May 1998 8 Expires November 1999
they would like to drop the connection after the current they would like to drop the connection after the current
request/response. These requirements are open issues. request/response. These requirements are open issues.
4.2.2 Store Location Models 4.2.2 Store Location Models
CAP MUST allow CUAs with local stores and CUAs without local stores. CAP MUST allow CUAs with local stores and CUAs without local stores.
SINGLE REMOTE CS SINGLE REMOTE CS
CAP MUST support the store location model where a CUA needs to CAP MUST support the store location model where a CUA needs to
skipping to change at line 442 skipping to change at line 443
CAP MUST support the model where a CUA can retrieve everything from CAP MUST support the model where a CUA can retrieve everything from
multiple local CS and periodically synchronize them with multiple multiple local CS and periodically synchronize them with multiple
remote CS. When a CAP connection is not established, the CUA can remote CS. When a CAP connection is not established, the CUA can
still function. When the CUA re-establishes a connection with each still function. When the CUA re-establishes a connection with each
remote CS, it can update the remote CS with information modified remote CS, it can update the remote CS with information modified
while disconnected. In addition, the CS associated with the CAP while disconnected. In addition, the CS associated with the CAP
connection can update any of the local CS with information that was connection can update any of the local CS with information that was
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
9 Expires May 1998 9 Expires November 1999
modified while it was disconnected from the remote CS. Multiple local modified while it was disconnected from the remote CS. Multiple local
and remote CS can be updated in sequence. and remote CS can be updated in sequence.
When remote and local CSs are involved, it MUST be possible to When remote and local CSs are involved, it MUST be possible to
identify conflicts between the local and remote CSs. It is the identify conflicts between the local and remote CSs. It is the
responsibility of the CUA to resolve conflicts. responsibility of the CUA to resolve conflicts.
"Modified information" includes new, changed and deleted components, "Modified information" includes new, changed and deleted components,
as well as properties on calendars and components. as well as properties on calendars and components.
skipping to change at line 498 skipping to change at line 499
Attendees values can be Qualified CalIDs of varying schemes. For Attendees values can be Qualified CalIDs of varying schemes. For
example: example:
ATTENDEE[...]:mailto:a@example.com ATTENDEE[...]:mailto:a@example.com
ATTENDEE[...]:irip://cal-1.example.com/b ATTENDEE[...]:irip://cal-1.example.com/b
ATTENDEE[...]:cap://calendar.example.com/c ATTENDEE[...]:cap://calendar.example.com/c
Editor Note: The MAILTO URL is illustrating an "iMIP" URL. Editor Note: The MAILTO URL is illustrating an "iMIP" URL.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
10 Expires May 1998 10 Expires November 1999
CAP MUST provide a way for the CUA to determine whether or not the CS CAP MUST provide a way for the CUA to determine whether or not the CS
supports optional or varying capabilities. For example: supports optional or varying capabilities. For example:
- Is a particular optional feature (like fan out, or calendar - Is a particular optional feature (like fan out, or calendar
access rights) supported? access rights) supported?
- Determine what, if any, limitation the CS imposes on unbounded - Determine what, if any, limitation the CS imposes on unbounded
recurrence rules. recurrence rules.
- Provide a way for the CUA to determine what, if any, limitations - Provide a way for the CUA to determine what, if any, limitations
skipping to change at line 555 skipping to change at line 556
When deleting a calendar, all sub-calendars of the calendar MUST When deleting a calendar, all sub-calendars of the calendar MUST
be deleted. This is an open issue. be deleted. This is an open issue.
- A CUA can delete a calendar regardless of whether or not the - A CUA can delete a calendar regardless of whether or not the
calendar has any entities in it. calendar has any entities in it.
- A CUA can set and retrieve properties of a calendar or sub- - A CUA can set and retrieve properties of a calendar or sub-
calendar on a CS. calendar on a CS.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
11 Expires May 1998 11 Expires November 1999
This should include the ability to set and retrieve standard and This should include the ability to set and retrieve standard and
custom properties, the time zone of a calendar, and the custom properties, the time zone of a calendar, and the
operational hours of a calendar. operational hours of a calendar.
For example, the CUA may want to schedule an event based on the For example, the CUA may want to schedule an event based on the
operational hours of a calendar. operational hours of a calendar.
4.3.1 Deferred Requirements for Operations on a Calendar 4.3.1 Deferred Requirements for Operations on a Calendar
CAP is not required to specify: CAP is not required to specify:
skipping to change at line 610 skipping to change at line 611
- How the CUA can modify, add or delete an arbitrary component - How the CUA can modify, add or delete an arbitrary component
property within a specified calendar. property within a specified calendar.
For example, modify the SUMMARY property on a calendar For example, modify the SUMMARY property on a calendar
component. component.
- How the CUA can modify a parameter of a multi-valued component - How the CUA can modify a parameter of a multi-valued component
property within a specified calendar. property within a specified calendar.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
12 Expires May 1998 12 Expires November 1999
For example, modify the PARTSTAT parameter on an ATTENDEE For example, modify the PARTSTAT parameter on an ATTENDEE
property associated with a particular attendee on a calendar property associated with a particular attendee on a calendar
component. component.
- How the CUA can add or modify attachment properties on a - How the CUA can add or modify attachment properties on a
specified component. specified component.
The attachments may be large, and the CUA ought not have to The attachments may be large, and the CUA ought not have to
resend the entire component. resend the entire component.
skipping to change at line 665 skipping to change at line 666
- How the CUA can modify all instances of a recurring component - How the CUA can modify all instances of a recurring component
that occur before a specified date, or after a particular date. that occur before a specified date, or after a particular date.
Open issue: whether the following requirements related to expansion Open issue: whether the following requirements related to expansion
of recurrence are deferred. of recurrence are deferred.
- How the CUA can request the CS to send down components with or - How the CUA can request the CS to send down components with or
without expansion of recurring calendar components. without expansion of recurring calendar components.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
13 Expires May 1998 13 Expires November 1999
- CAP MUST permit the CS to refuse this request, so that if the CS - CAP MUST permit the CS to refuse this request, so that if the CS
normally provides expansions of recurring calendar components, it normally provides expansions of recurring calendar components, it
can refuse the request to not expand. However, the CS MUST can refuse the request to not expand. However, the CS MUST
terminate the expansion eventually. terminate the expansion eventually.
- How the CUA can find out, and perhaps change, the length of time - How the CUA can find out, and perhaps change, the length of time
for which recurring calendar components are expanded. for which recurring calendar components are expanded.
- How the CUA can retrieve, and perhaps set, the period for or - How the CUA can retrieve, and perhaps set, the period for or
number of recurrences expanded on a recurring component. number of recurrences expanded on a recurring component.
skipping to change at line 721 skipping to change at line 722
- Modify inline attachment to URL; provide URL to fetch. - Modify inline attachment to URL; provide URL to fetch.
- Merge or aggregate more than one calendar. - Merge or aggregate more than one calendar.
- Lock access to calendar. - Lock access to calendar.
- Delayed or asynchronous transactions. - Delayed or asynchronous transactions.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
14 Expires May 1998 14 Expires November 1999
- The CUA requesting a size limit before retrieving components - The CUA requesting a size limit before retrieving components
from the CS. The CS might send partial components if the from the CS. The CS might send partial components if the
component's size exceeded the limit. CAP would permdit the CS to component's size exceeded the limit. CAP would permdit the CS to
refuse the request or give its preferred value. refuse the request or give its preferred value.
- The CS synchronizing 2 calendars. - The CS synchronizing 2 calendars.
- How the CUA tells the CS to prevent conflicts with respect to an - How the CUA tells the CS to prevent conflicts with respect to an
individual component in the calendar. The scenario for this is that individual component in the calendar. The scenario for this is that
a component could be marked for "allow no conflicts", and the CS a component could be marked for "allow no conflicts", and the CS
skipping to change at line 778 skipping to change at line 779
CUA could ask for the DTSTART, DTEND and SUMMARY properties for CUA could ask for the DTSTART, DTEND and SUMMARY properties for
all components with DTSTART later than 9:00 p.m. today. all components with DTSTART later than 9:00 p.m. today.
4.5.2 Query Capabilities 4.5.2 Query Capabilities
CAP MUST allow the CUA to retrieve CalIDs, component UIDs or CAP MUST allow the CUA to retrieve CalIDs, component UIDs or
component hierarchical names (open issue) from a given calendar, component hierarchical names (open issue) from a given calendar,
using queries which specify: using queries which specify:
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
15 Expires May 1998 15 Expires November 1999
- How the CUA can retrieve data from multiple calendars. - How the CUA can retrieve data from multiple calendars.
This requirement allows the CUA to display multiple calendars to This requirement allows the CUA to display multiple calendars to
the user. This requirement does not constrain this functionality the user. This requirement does not constrain this functionality
to a single request as it may be done in multiple requests. to a single request as it may be done in multiple requests.
- How the CUA to retrieve any named property for a calendar or - How the CUA to retrieve any named property for a calendar or
component. component.
For example, the CUA can retrieve the SUMMARY property for a For example, the CUA can retrieve the SUMMARY property for a
skipping to change at line 835 skipping to change at line 836
This requirement does not state that the components MUST be This requirement does not state that the components MUST be
retrieved in their entirety in the same interaction as the retrieved in their entirety in the same interaction as the
query; the query and the component retrieval can be separate query; the query and the component retrieval can be separate
interactions between the CUA and the CS. interactions between the CUA and the CS.
CAP MUST allow synchronization, meaning at a minimum that the CUA is CAP MUST allow synchronization, meaning at a minimum that the CUA is
able to find and retrieve new, modified or deleted entries for a able to find and retrieve new, modified or deleted entries for a
given time period. The CUA MUST be able to find out which entries given time period. The CUA MUST be able to find out which entries
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
16 Expires May 1998 16 Expires November 1999
have been added, modified or deleted since it last synchronized, in have been added, modified or deleted since it last synchronized, in
order to operate in disconnected mode. This requirement may be order to operate in disconnected mode. This requirement may be
satisfied using the query requirements already defined. satisfied using the query requirements already defined.
4.5.3 Specific Queries 4.5.3 Specific Queries
These are specific scenarios required by calendaring operations which These are specific scenarios required by calendaring operations which
may require special attention to ensure that they can be done with may require special attention to ensure that they can be done with
the querying and lookup functionality of CAP. the querying and lookup functionality of CAP.
skipping to change at line 891 skipping to change at line 892
supported on a named calendar. supported on a named calendar.
- How the CUA can query the names of all properties which exist on - How the CUA can query the names of all properties which exist on
a given calendar, or the properties which exist on a given a given calendar, or the properties which exist on a given
component. component.
- How the CUA can query the names of component properties - How the CUA can query the names of component properties
supported by a CS. supported by a CS.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
17 Expires May 1998 17 Expires November 1999
- How the CUA can query the time zones supported by the CS - How the CUA can query the time zones supported by the CS
4.5.5 Deferred Requirements for Search 4.5.5 Deferred Requirements for Search
CAP is not required to specify: CAP is not required to specify:
- How to roll up free/busy information for a number of calendars - How to roll up free/busy information for a number of calendars
(perhaps sub-calendars) into a single free/busy component. (perhaps sub-calendars) into a single free/busy component.
- How to fetch all components marked for deletion in a certain - How to fetch all components marked for deletion in a certain
skipping to change at line 946 skipping to change at line 947
CAP MUST specify, subject to access control: CAP MUST specify, subject to access control:
- How a list of designates is created. - How a list of designates is created.
- How the CS knows that a user is a valid designate, through - How the CS knows that a user is a valid designate, through
authentication or some other mechanism. authentication or some other mechanism.
- How the CUA can delegate to another calendar user. - How the CUA can delegate to another calendar user.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
18 Expires May 1998 18 Expires November 1999
4.8 Notification (deferred) 4.8 Notification (deferred)
There are no notification features that are required in CAP. There are no notification features that are required in CAP.
Notification is deemed not to be a requirement, because: Notification is deemed not to be a requirement, because:
- A CUA can poll the CS for new/changed/deleted components, - A CUA can poll the CS for new/changed/deleted components,
including new ITIP messages. This functionality is needed to including new ITIP messages. This functionality is needed to
support synchronization. support synchronization.
skipping to change at line 1003 skipping to change at line 1004
- CUA grants free/busy view rights on a given calendar to a - CUA grants free/busy view rights on a given calendar to a
calendar user. calendar user.
- CUA grants full access rights on a given calendar to a calendar - CUA grants full access rights on a given calendar to a calendar
user. user.
- CS performs calendar access rights inheritance on sub-calendars. - CS performs calendar access rights inheritance on sub-calendars.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
19 Expires May 1998 19 Expires November 1999
- CUA grants/denies access rights to individual properties of - CUA grants/denies access rights to individual properties of
individual components. individual components.
For example, user A can see subject of event B, or user A can For example, user A can see subject of event B, or user A can
set time of event B. set time of event B.
- CUA can set operation limits for user A on calendar B. - CUA can set operation limits for user A on calendar B.
For example: For example:
skipping to change at line 1059 skipping to change at line 1060
CSID in a group CSID in a group
- CUA can send a single schedule request to the CS, where the - CUA can send a single schedule request to the CS, where the
attendee list includes a group. The CS then fans out the request. attendee list includes a group. The CS then fans out the request.
Fanning out might be achieved by forwarding the request to all Fanning out might be achieved by forwarding the request to all
members of a group, or by placing the request on the calendar of members of a group, or by placing the request on the calendar of
every member of the group. The members of the group may be on every member of the group. The members of the group may be on
multiple CSs. multiple CSs.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
20 Expires May 1998 20 Expires November 1999
- CUA can schedule one CSID by scheduling one instance from a - CUA can schedule one CSID by scheduling one instance from a
pool. pool.
- Each group/pool itself has properties. - Each group/pool itself has properties.
- Access restrictions can be set on a group/pool, to restrict who - Access restrictions can be set on a group/pool, to restrict who
can get/set properties and who can schedule the group/pool. can get/set properties and who can schedule the group/pool.
4.11 CAP Non-requirements 4.11 CAP Non-requirements
skipping to change at line 1115 skipping to change at line 1116
and how results are returned. and how results are returned.
- Whether all sub-calendars of a deleted calendar MUST be deleted. - Whether all sub-calendars of a deleted calendar MUST be deleted.
- Whether the ability to set a policy of turning down requests - Whether the ability to set a policy of turning down requests
that exceed a maximum duration is a requirement. that exceed a maximum duration is a requirement.
- Whether expansion of recurrences is required. - Whether expansion of recurrences is required.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
21 Expires May 1998 21 Expires November 1999
- Whether or not CAP operations support bounding the latency of - Whether or not CAP operations support bounding the latency of
responses to operations. responses to operations.
6. Acknowledgments 6. Acknowledgments
The following have provided input in the drafting of this memo: The following have provided input in the drafting of this memo:
Lisa Lippert, Surendra Reddy, Richard Shusterman. Lisa Lippert, Surendra Reddy, Richard Shusterman.
7. Bibliography 7. Bibliography
skipping to change at line 1172 skipping to change at line 1173
N:Dawson;Frank N:Dawson;Frank
ORG:Lotus Development Corporation ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; Raleigh; ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; Raleigh;
NC;27613-3502;USA NC;27613-3502;USA
TEL;TYPE=WORK,MSG:+1-617-693-8728 TEL;TYPE=WORK,MSG:+1-617-693-8728
TEL;TYPE=WORK,FAX:+1-617-693-5552 TEL;TYPE=WORK,FAX:+1-617-693-5552
EMAIL;TYPE=INTERNET:Frank_Dawson@Lotus.com EMAIL;TYPE=INTERNET:Frank_Dawson@Lotus.com
URL:http://home.earthlink.net/~fdawson URL:http://home.earthlink.net/~fdawson
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
22 Expires May 1998 22 Expires November 1999
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0 VERSION:3.0
FN:Tony Small FN:Tony Small
N:Small;Tony N:Small;Tony
ORG:Microsoft Corporation ORG:Microsoft Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; Redmond;WA; ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; Redmond;WA;
98052-6399;USA 98052-6399;USA
TEL;TYPE=WORK,MSG:+1-206-703-2190 TEL;TYPE=WORK,MSG:+1-206-703-2190
skipping to change at line 1229 skipping to change at line 1230
EMAIL;TYPE=INTERNET:doug.royer@sun.com EMAIL;TYPE=INTERNET:doug.royer@sun.com
END:VCARD END:VCARD
This work is part of the Internet Engineering Task Force Calendaring This work is part of the Internet Engineering Task Force Calendaring
and scheduling Working Group. The chairmen of that working group are: and scheduling Working Group. The chairmen of that working group are:
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0 VERSION:3.0
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
23 Expires May 1998 23 Expires November 1999
FN:Anik Ganguly FN:Anik Ganguly
N:Ganguly;Anik N:Ganguly;Anik
ORG:Open Text, Inc. ORG:Open Text, Inc.
ADR;TYPE=WORK,POSTAL,PARCEL:;;38777 West Six Mile Road Suite 101; ADR;TYPE=WORK,POSTAL,PARCEL:;;38777 West Six Mile Road Suite 101;
Livonia;MI;48152;USA Livonia;MI;48152;USA
TEL;TYPE=WORK,MSG:+1-734-542-5955 TEL;TYPE=WORK,MSG:+1-734-542-5955
EMAIL;TYPE=INTERNET:ganguly@acm.org EMAIL;TYPE=INTERNET:ganguly@acm.org
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
skipping to change at line 1275 skipping to change at line 1276
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 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.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
24 Expires May 1998 24 Expires November 1999
 End of changes. 32 change blocks. 
41 lines changed or deleted 42 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/