draft-ietf-calsch-capreq-01.txt   draft-ietf-calsch-capreq-02.txt 
Network Working Group Andre Courtemanche, CS&T Network Working Group Andre Courtemanche, CS&T
Internet Draft - CAP Requirements Tony Small, Lisa Lippert, Microsoft Internet Draft Frank Dawson, Lotus
<draft-ietf-calsch-capreq-01.txt> Frank Dawson, Lotus <draft-ietf-calsch-capreq-02.txt> Steve Mansour, Netscape
Steve Mansour, Netscape
Pete O'Leary, Amplitude Pete O'Leary, Amplitude
Expires 6 months after: August 6, 1998 Doug Royer, Sun Microsystems
Tony Small, Microsoft
Expires six months after: November 18, 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, and documents of the Internet Engineering Task Force (IETF), its areas,
its working groups. Note that other groups may also distribute working and its working groups. Note that other groups may also distribute
documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts are draft documents valid for a maximum of six
Internet-Drafts may be updated, replaced, or made obsolete by other months. Internet-Drafts may be updated, replaced, or made obsolete by
documents at any time. It is not appropriate to use Internet-Drafts as other documents at any time. It is not appropriate to use Internet-
reference material or to cite them other than as a "working draft" or Drafts as reference material or to cite them other than as a "working
"work in progress". draft" or "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 ftp.ietf.org (US East Coast), nic.nordu.net (Europe), Directories on ftp.ietf.org (US East Coast), nic.nordu.net
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Abstract Abstract
The Calendar Access Protocol (CAP) protocol defines calendar The Calendar Access Protocol (CAP) is an Internet protocol for
administration and calendar component management on calendar stores by accessing an [ICAL] based calendar store (CS) from a calendar user
owners, designates, and others. The purpose of this document is to set agent (CUA). The purpose of this document is to set forth a list of
forth a list requirements that CAP must address in order to address the requirements that CAP MUST address in order to meet the needs of the
needs of the calendaring and scheduling community. calendaring and scheduling community.
Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 1 This document is based on discussions within the Internet Engineering
Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.
More information about the IETF CALSCH working group activities can
be found on the IMC web site at http://www.imc.org, the IETF web site
at http://www.ietf.org/html.charters/calsch-charter.html. Refer to
the references within this document for further information on how to
access these various documents.
Distribution of this document is unlimited. Comments and suggestions
for improvement should be sent to the authors.
Copyright (C) The Internet Society 1998. All Rights Reserved.
Change History
Version 00 - Initial draft.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
1 Expires May 1998
Version 01 - Revised format; Included initial set of scenarios and
requirements.
Version 02 - Revised format; Significant modification to set of
requirements. Included lists of requirements that are deferred to
later versions of CAP or to other drafts.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
2 Expires May 1998
Table of Contents
1. Introduction........................................................4
2. Terminology.........................................................4
3. Relationship To iCalendar, iTIP and iMIP/iRIP.......................7
4. Requirements........................................................7
4.1 Basic Usage ......................................................7
4.2 Infrastructure ...................................................8
4.2.1 Connection Models .............................................8
4.2.2 Store Location Models .........................................9
4.2.3 Calendar Stores ..............................................10
4.2.4 Exception Reporting ..........................................11
4.3 Operations on a Calendar ........................................11
4.3.1 Deferred Requirements for Operations on a Calendar ...........12
4.4 Component Management ............................................12
4.4.1 Recurrence ...................................................13
4.4.2 Calendar and Component Policies ..............................14
4.4.3 Deferred Requirements for Component Management ...............14
4.5 Lookup, Query and Discovery .....................................15
4.5.1 Lookup .......................................................15
4.5.2 Query Capabilities ...........................................15
4.5.3 Specific Queries .............................................17
4.5.4 Discovery ....................................................17
4.5.5 Deferred Requirements for Search .............................18
4.6 Security ........................................................18
4.7 Designates and Delegation .......................................18
4.8 Notification (deferred) .........................................19
4.9 Access Control (deferred) .......................................19
4.10 Resource Groups and Pools (deferred) ...........................20
4.11 CAP Non-requirements ...........................................21
5. Open Issues........................................................21
6. Acknowledgments....................................................22
7. Bibliography.......................................................22
8. Authors' Address...................................................22
9. Full Copyright Statement...........................................24
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
3 Expires May 1998
1. Introduction 1. Introduction
1.1 Assumptions The Calendar Access Protocol (CAP) is an Internet protocol for
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
requirements that CAP MUST address in order to meet the needs of the
calendaring and scheduling community.
1. The data elements of CAP are based on [ICAL]. 2. Terminology
2. The CAP protocol is intended to support both connected and The terminology used in [ICAL], [ITIP] and [IMIP] are also used
synchronization operation. within this memo.
1.2 Definitions Calendar
A collection of logically related objects or entities each of
which may be associated with a calendar date and possibly time of
day. These entities can include other calendar properties or
calendar components. In addition, a calendar might be
hierarchically structured and consist of other sub-calendars. The
[ICAL] defines calendar properties, calendar components and
component properties. A calendar is identified by its unique
calendar identifier.
The terms Calendar User (CU), Calendar User Agent (CUA), Calendar Calendar Access Protocol
Store, and Calendar Service (CS) are defined in [ICMS]. An Internet protocol that allows a CUA to access and operate on a
CS.
2. Scenarios Calendar Access Rights
Some method for specifying permitted operational capabilities for
a calendar user.
These are the usage scenarios used to drive the requirements list. Calendar Component
Understanding these scenarios and how they are useful to clients and An entity within a calendar. Types of calendar components include
administrators will help with understanding why these requirements were events, to-dos, journals, alarms, time zones and freebusy data. A
chosen. However, these scenarios are not an exhaustive list. calendar component consists of component properties and possibly
other sub-components. For example, an event can consist of an
alarm component.
2.1 Access Control Calendar Component Properties
An attribute of a particular calendar component. Some calendar
component properties are applicable to different types of
calendar components. For example, DTSTART is applicable to
VEVENT, VTODO, VJOURNAL calendar components. Other calendar
components are applicable only to an individual type of calendar
component. For example, TZURL is only applicable to VTIMEZONE
calendar components.
A user MUST be able to: Calendar Identifier
Also known as "CalID". A globally unique identifier associated
with a calendar within a CS.
* Create an event, to-do, or journal entry such that only the creator Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
can see all properties and others can see only the start and end 4 Expires May 1998
times. Calendar Policy
An operational restriction on the access or manipulation of a
calendar. For example, "events MUST be scheduled in unit
intervals of one hour".
* Create an event or to-do such that only the attendees can see all Calendar Properties
properties and others can see only the start and end times. An attribute of a calendar. The attibute applies to the calendar,
as a whole. For example, CALSCALE specifies the calendar scale
(e.g., GREGORIAN) for the whole calendar.
* Create an event, to-do, or journal entry such that all properties can Calendar Service
be seen by anyone. An implementation of an application that manages one or more
calendars.
* Define who can add items to their calendar store. Calendar Store
Also known as "CS". The data model definition for a Calendar
Service.
* Enable another person to act on behalf of the user. Calendar Store Identifier
Also known as "CSID". The identifier for an individual calendar
store. A CSID consists of the user, password, host and port
portions of a "Common Internet Scheme Syntax" part of a URL, as
defined by [RFC1738].
* Fetch components from another user's calendar, subject to access Calendar Store Components
control Components maintained in a Calendar Store that are not part of
any calendar.
* Put requests for user A on user A's calendar, subject to access Calendar Store Properties
control Properties maintained in a Calendar Store that are not part of
any calendar.
* "Direct book" an event or to-do on user A's calendar, subject to Calendar User
access control The entity that is associated with the credentials presented by
the Calendar User Agent to the Calendar Store.
* Fetch user A's busy time, subject to access control Calendar User Agent
Also known as "CUA". The CUA is the software client operated by
the calendar user.
* Perform any calendar operation on behalf of user A, subject to access Calendaring and Scheduling System
control. The computer sub-system that provides the services for accessing,
manipulating calendars and scheduling calendar components.
2.2 Implementation Options Connected Mode
A mobile computing mode where the CUA is directly connected to
the calendar store.
A server vendor may decide to only support VEVENT components and not Delegate
support VTODO and VJOURNAL components. The client needs to query the Is a calendar user (sometimes called the delegatee) who has been
server to see which components are supported. assigned participation in a scheduled calendar component (e.g.,
VEVENT) by one of the attendees in the scheduled calendar
component (sometimes called the delegator). An example of a
delegate is a team member told to go to a particular meeting.
Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 2 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
5 Expires May 1998
Designate
Is a calendar user who is authorized to act on behalf of another
calendar user. An example of a designate is an assistant.
2.3 Notification Disconnected Mode
A mobile computing mode where a CUA can be disconnected from a
calendar store. When the CUA is disconnected, it is in the
disconnected mode.
Server implementations may wish to allow clients to register for Fan Out
events. When the event occurs, the server can notify the client. The process by which a calendar store forwards scheduling
operations to the attendees not associated with the current
calendar.
The following notification scenarios MUST be supported by the protocol Hierarchical Calendars
design: A CS feature where calendars may contain sub-calendars. The top-
most calendar in a hierarchy of calendars is called the root
calendar. There may be multiple root calendars in a single CS.
Within a hierarchy of calendars, all sub-calendars have a
calendar with a parent topographical relationship. In addition,
sub-calendars may have sub-calendars (child topographical
relationship). In addition, the sub-calendar may have one or more
calendars with a sibling topographical relationship.
* A client wants to be notified by the server whenever any change is High Bandwidth Connection
made to a particular calendar store. A communications connection supporting high transfer rates;
transfer rates commonly found within a LAN.
* An alarm for a VEVENT or VTODO has gone off for a particular calendar Local Store
store. A store which is on the same hardware as the CUA.
2.4 Search Scenarios Low Bandwidth Connection
A communications connection supporting slow transfer rates;
transfer rates commonly found in modem technology.
The following searches MUST be supported in some manner. Relative Calendar Identifier
Also known as "Relative CalID". A relative identifier for an
individual calendar in a calendar store. A Relative CalID
consists of the portion of the "scheme part" of a Qualified
CalID, following the Calendar Store Identifier. This is the same
as the "URL path" of the "Common Internet Scheme Syntax" portion
of a URL, as defined by [RFC1738].
* Search for all items of a certain type (e.g. VEVENT) Qualified Calendar Identifier
Also known as "Qualified CalID". A complete Internet identifier
for a specific calendar. A Qualified CalID consists of a CAP
specific "scheme" and "scheme part" portion of a URL, as defined
in [RFC1738]. A Qualified CalID are written only with the graphic
printable characters of the US-ASCII coded character set.
* Search for all items with a start time greater than x OR an end time Remote Store
less than y. A store which is not on the same hardware as the CUA.
* Search for all items of type VEVENT, with start and end types such Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
that the event overlaps a certain period (i.e. 24 hours of one day) 6 Expires May 1998
Sub-calendars
Calendars that are contained within other calendars in a
hierarchical relationship.
* Search for all items with a display name containing a string S 3. Relationship To iCalendar, iTIP and iMIP/iRIP
* Search for all items with an attendee list that contains the user S The CAP data elements MUST be based on the calendar architecture set
forth in [ICAL]. More precisely, CAP will define an Internet protocol
for accessing a CS that consists of one or more calendars, each
consisting of numerous [ICAL] components. The definition of CAP might
necessitate adding components, properties, parameters and other
elements beyond those defined in [ICAL]. These additions MUST be
defined in a manner consistent with and upwards compatible to the
data model defined by [ICAL].
3. Requirements Where it makes practical sense, CAP SHOULD make use of the scheduling
workflow defined by [ITIP].
The requirements are broken into the following categories: CAP will not require that [IMIP] or [IRIP] MUST be used to
communicate with other calendar users.
* Basic 4. Requirements
* Administration 4.1 Basic Usage
* Component Management CAP MUST specify:
There is some overlap between the categories. All requirements in this - How to provide a standard protocol to allow a CUA to
section are MUST HAVE features for the protocol draft to address. interoperate with a CS.
3.1 Basic requirements - Using only CAP, a CUA MUST be able to access and manipulate a
calendar. CAP MUST provide the complete, if minimal, functionality
that allows a CUA to access a calendar.
The CAP protocol design must: - How to allow a CUA to be developed independently of a CS and a
CS independently of a CUA.
1. Support the model of storing calendar data only on the server. - How to allow an organization to have a mixture of CUAs and CSs
from different vendors. With CAP, any CUA in the organization MUST
be able to interoperate with any CS.
2. Support the model of storing calendar data on both the client and - How to allow for a single CUA to access multiple CSs or
the server, with some kind of synchronization. calendars.
3. Support a framework for authentication of a calendar user For example, a CUA MUST be able to create calendar components on
multiple calendars and/or retrieve calendar components from
multiple calendars.
4. Allow one calendar user to act as a designate or proxy for another - How to allow for a rich featured CUA.
user.
5. Support the transport of encrypted data between the CUA and the CS. For example, allow a CUA to be part of a client which offers
rich calendaring, scheduling and related functionality, with the
possibility of extending from concepts and services offered by
CAP, while still using CAP to access a calendar.
Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 3 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
7 Expires May 1998
- How to extend the base features in CAP.
6. Define calendar addresses that support hierarchical names. - How to allow for interpersonal applications to be calendar
enabled.
7. Specify the granularity of access control on calendars. See the For example, a chat application MUST be able to offer a calendar
access control scenarios above. button to create an event between the two or more parties.
8. Allow clients to determine what data components (i.e. VEVENT, VTODO) - How to allow for non-interpersonal applications to be calendar
a CAP server supports. enabled.
9. Define error codes to be returned for improper commands, unsupported For example, a reservation system MUST be able to retrieve and
commands, and command failures. update calendar components from a calendar. Other examples of
non-interpersonal applications include event planning, resource
scheduling, and Human Asset Management (HAM).
10. Allow users to search for calendar stores. - How to allow for CUAs without local store and with minimal
memory.
11. Allow calendar users to control the access that others have to For example, a cell phone MUST be able to act as a CUA.
their calendar. See access control scenarios above.
12. Allow a number of simple operations on calendar stores to be - How to allow for CUAs with local store that can be kept
grouped such that if any operation cannot be completed on all synchronized with the remote store.
calendar stores, then no change is made to any calendar store.
13. Support server-to-client notification. See notification scenarios For example, a robust featured application might act as a CUA
above. and also provide extra functionality using the local store.
14. Allow the server implementation to return a referral when a request - How to allow for CUAs over disconnected, low-bandwidth
was made for a calendar or CU located elsewhere. Servers must not be connections.
required to make referrals.
15. Support functionality such that the client is not forced to remain For example, a PDA MUST be able to act as a CUA and interoperate
connected and waiting while a command is in progress. One possible way with a CS over a low-bandwidth wireless connection.
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 - How to allow for CUAs over high bandwidth connections.
property for a human-readable name.
3.2 Administration Requirements For example, a PC MUST be able to act as a CUA and interoperate
with a CS over a high-speed Ethernet connection.
In order to provide some interoperability of administration functions 4.2 Infrastructure
on calendars, the CAP protocol design must:
1. Allow a CUA to connect to the CAP server and authenticate the CU. This section defines a set of infrastructure requirements for CAP.
2. Allow creation and deletion of calendar stores. 4.2.1 Connection Models
3. Provide a way to set and change ownership of a calendar. CAP MUST support a number of CUA-to-CS connection models. In
particular, CAP MUST allow connected and disconnected operation.
4. Support setting access control lists on a calendar. CUAs and CSs often support the "connected model", where clients
maintain long-term connections to servers. Because of this, CAP MUST
specify how the connection between a CUA and a CS can be maintained.
5. Support retrieving access control lists from a calendar. CAP MUST NOT prevent servers from dropping client connections,
particularly idle client connections. CAP MUST provide some ways for
clients to indicate that they would like to stay connected, or that
6. Enumerate the access levels that are possible on a calendar. Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
8 Expires May 1998
they would like to drop the connection after the current
request/response. These requirements are open issues.
7. Support functions to add, modify, and delete calendar properties. 4.2.2 Store Location Models
8. Allow users to list calendar stores (subject to access control). CAP MUST allow CUAs with local stores and CUAs without local stores.
3.3 Component Management Requirements SINGLE REMOTE CS
Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 4 CAP MUST support the store location model where a CUA needs to
retrieve everything from a single remote CS. In this model, the CUA
does not have a local CS. Instead, a single CS resides remotely and
is accessed through CAP. The client MUST always establish the CAP
connection in order to function.
In order to provide interoperability of component management on MULTIPLE REMOTE CS
calendars, the CAP protocol design must:
1. Allow users to create, modify, and delete components in a calendar CAP MUST support the model where a CUA has no local CS, but needs to
store. retrieve everything from multiple remote CS. In this model, the CUA
does not have any local CS. Instead, multiple CSs reside remotely and
are accessed through CAP. The client MUST always establish one or
more CAP connections in order to function.
2. Allow users to create an invitation to an event or to-do in someone SINGLE LOCAL, SINGLE REMOTE CS
else's calendar store (subject to access control).
3. Allow users to retrieve the busy time on a calendar store. CAP MUST support the model where a CUA can retrieve everything from
the local store and periodically synchronize the local store with a
single remote CS. When there is no CAP connection, the CUA can still
function. When the CAP connection is re-established, the CUA can
update the remote CS with information modified on the local CS while
it was disconnected. In addition, the CUA can update its single local
CS with information that was modified on the remote CS while the CUA
was disconnected.
4. Allow the CUA to fetch a list of components based on a query. The SINGLE LOCAL, MULTIPLE REMOTE CS
query language must support the scenarios outlined above.
5. Allow a CUA to specify which properties will be returned in the CAP MUST support the model where a CUA can retrieve everything from a
results of a fetch operation. The CUA should also be able to get the local CS and periodically synchronize with multiple remote CS. When
entire component (all properties). the CAP connection is not established, the CUA can still function.
When the CUA re-establishes a connection with each remote CS, it can
update the remote CS with information modified while disconnected. In
addition, the CUA can update the single local CS with information
that was modified on remote CS while the CUA was disconnected.
6. Allow CUA to fetch a set of alarms/reminders that are set to go off MULTIPLE LOCAL, MULTIPLE REMOTE CS
within a range of time.
7. Allow the CUA to register for and receive notifications from more CAP MUST support the model where a CUA can retrieve everything from
than one calendar and from more than one calendar server. multiple local CS and periodically synchronize them with multiple
remote CS. When a CAP connection is not established, the CUA can
still function. When the CUA re-establishes a connection with each
remote CS, it can update the remote CS with information modified
while disconnected. In addition, the CS associated with the CAP
connection can update any of the local CS with information that was
8. Allow the CUA to use the result of a query to perform modify, Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
delete, and other operations. 9 Expires May 1998
modified while it was disconnected from the remote CS. Multiple local
and remote CS can be updated in sequence.
Also, When remote and local CSs are involved, it MUST be possible to
identify conflicts between the local and remote CSs. It is the
responsibility of the CUA to resolve conflicts.
9. The protocol will be designed such that a subset of component "Modified information" includes new, changed and deleted components,
properties can be updated without having to specify all existing as well as properties on calendars and components.
component properties.
10. The protocol draft must specify how and where (or how to tell 4.2.3 Calendar Stores
where) expansion of recurring events will occur.
3.4 Open Issues The diagram below describes the data objects maintained in a CS. CAP
defines how data in the CS is manipulated. The data consists of:
1. Given that access control to calendar stores must be addressed, is - Calendar Store properties, e.g. local time zone
there a need to standardize the way Calendar Users are identified?
4. Future Work - Calendars, e.g. a user's calendar
These are desirable areas for future work on calendaring access. In - Calendar properties, e.g. a user name
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. - Calendar components, e.g. an iCAL VEVENT
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. - Component properties, e.g. DTSTART on a VEVENT
3. Archiving (import and export) of calendar stores. - Property attributes, e.g. TZID on DTSTART
Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 5 - Access control rights (deferred)
4. Group names can be used to invite a list of attendees to an event or A calendar may contain other calendars to form a hierarchy. Every
to-do. Group names can be used in setting access to events and calendar has its own properties.
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 CAP does not define users. CAP does not define any default or implied
completed successfully on all calendar stores involved. For example, relationship between a user and a calendar. Users, via a CUA,
do not do the transaction at all or complete the operation on as many authenticate themselves to a CS to access information. All access is
calendar stores as possible. In either case, any failures must be subject to access control.
reported to the client.
6. Support the addition of functionality extensions. Commands on the Editor Note: Insert calendar store diagram here. In the interim
wire should be able invoke the extended functionality. (This is refer to http://www.imc.org/ietf-calendar/csmodel.jpg
something akin to server plug-ins.)
7. Allow for Draft storage of components Calendars are always referenced by their CalIDs. Open issue: whether
calendars can also be referenced by their hierarchical name.
8. Add, modify, or delete components based on a query of calendar CalIDs are used in all operations
stores.
9. Get components from multiple stores in a single command. Attendees values can be Qualified CalIDs of varying schemes. For
example:
10. The capability to list calendar stores based on properties. ATTENDEE[...]:mailto:a@example.com
ATTENDEE[...]:irip://cal-1.example.com/b
ATTENDEE[...]:cap://calendar.example.com/c
11. The capability to perform an operation on a number of calendar Editor Note: The MAILTO URL is illustrating an "iMIP" URL.
stores.
5. Acknowledgments Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
10 Expires May 1998
CAP MUST provide a way for the CUA to determine whether or not the CS
supports optional or varying capabilities. For example:
The following have provided input in the drafting of this memo: - Is a particular optional feature (like fan out, or calendar
access rights) supported?
Mike Weston - Determine what, if any, limitation the CS imposes on unbounded
recurrence rules.
6. Bibliography - Provide a way for the CUA to determine what, if any, limitations
the CS imposes on date/time values. For example, there may be dates
in the past and future beyond which the CS cannot represent.
[ICMS] "Internet Calendaring Model Specification", Internet-Draft, July 4.2.4 Exception Reporting
1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt.
[ICAL] "Internet Calendaring and Scheduling Core Object Specification - The granularity of exception report can be at the level of the
iCalendar", Internet-Draft, July 1997, calendar, the calendar component, component property, or property
ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-02.txt. attribute as appropriate.
CAP MUST provide a way to determine the results of delayed
operations. Delayed operations arise from the use of other protocols
(IMIP, IRIP), which may take a long time to resolve. Delayed
operations have a return code and may have associated calendar data.
As an example, an ITIP request for free/busy information may result
in the delivery of a VFREEBUSY component. A CUA MUST be able to use
CAP to retrieve the VFREEBUSY component. If the operation failed, the
CUA MUST be able to determine the reply code. It is an open issue
whether CAP MUST support delayed operations and what that means, and
how results are returned.
4.3 Operations on a Calendar
A calendar is assumed to reside on a CS. CAP MUST specify:
- How a CUA can create a calendar or sub-calendar.
For example, sub-calendars might be used to organize calendar
information based on criteria defined by the CUA.
- How a CUA can rename a calendar or sub-calendar.
For example, the CUA may decide to change the name of a calendar
after the calendar has been created.
- How a CUA can delete a calendar or sub-calendar.
When deleting a calendar, all sub-calendars of the calendar MUST
be deleted. This is an open issue.
- A CUA can delete a calendar regardless of whether or not the
calendar has any entities in it.
- A CUA can set and retrieve properties of a calendar or sub-
calendar on a CS.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
11 Expires May 1998
This should include the ability to set and retrieve standard and
custom properties, the time zone of a calendar, and the
operational hours of a calendar.
For example, the CUA may want to schedule an event based on the
operational hours of a calendar.
4.3.1 Deferred Requirements for Operations on a Calendar
CAP is not required to specify:
- How to copy a calendar on a CS or between CSs.
- How a group operations on a set of calendars.
- How to undelete a calendar.
- Auto processing on scheduled components in a calendar that need
action.
For example, if someone tries to create a meeting on a calendar
for a user who is on vacation, the CS may automatically delegate
the meeting to another user.
4.4 Component Management
CAP MUST specify, subject to access control:
- How the CUA can create a component (event/to-do/journal) on a
calendar (direct booking)
- How the CUA can create a component on another user's calendar
This capability permits the CUA to create calendar components on
another calendar, other than their own, but does not necessarily
give them the capability to read or modify calendar components.
- How the CUA can modify a component on a given calendar
- How the CUA can delete a component from one or more calendars
- The requirement to delete from multiple calendars might be met
with separate requests.
- How the CUA can modify, add or delete an arbitrary component
property within a specified calendar.
For example, modify the SUMMARY property on a calendar
component.
- How the CUA can modify a parameter of a multi-valued component
property within a specified calendar.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
12 Expires May 1998
For example, modify the PARTSTAT parameter on an ATTENDEE
property associated with a particular attendee on a calendar
component.
- How the CUA can add or modify attachment properties on a
specified component.
The attachments may be large, and the CUA ought not have to
resend the entire component.
- How the CUA can send an attachment to the CS.
The attachment would be appended to a particular component.
- How the CUA can remove a specified attachment from the CS and
its property from the specified component.
- How hierarchical name can be used for all operations.
This requirement indicates that any calendaring or scheduling
operation performed on a component or calendar by specifying the
UID or CSID, MUST also be available by specifying the
hierarchical name. The two exceptions are the request for the
hierarchical name given the UID or vice versa.
Open Issue: This is still open to discussion.
CAP MUST also allow the CUA to do synchronization of two calendars to
which it has access.
4.4.1 Recurrence
CAP MUST specify, subject to access control:
- How the CUA can retrieve or delete a calendar component based on
the UID, and an optional RECURRENCE-ID.
For example, retrieve the single instance of a recurring meeting
by specifying both the UID for the recurring meeting and the
RECURRENCE-ID of the instance.
- How the CUA can modify or delete an instance of a recurring
component, or all recurrences.
- How the CUA can modify all instances of a recurring component
that occur before a specified date, or after a particular date.
Open issue: whether the following requirements related to expansion
of recurrence are deferred.
- How the CUA can request the CS to send down components with or
without expansion of recurring calendar components.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
13 Expires May 1998
- CAP MUST permit the CS to refuse this request, so that if the CS
normally provides expansions of recurring calendar components, it
can refuse the request to not expand. However, the CS MUST
terminate the expansion eventually.
- How the CUA can find out, and perhaps change, the length of time
for which recurring calendar components are expanded.
- How the CUA can retrieve, and perhaps set, the period for or
number of recurrences expanded on a recurring component.
This could be 0, infinity, a specific DTEND, or a consistent
length of time from "today" into the future.
4.4.2 Calendar and Component Policies
CAP MUST specify:
- How the CUA tells the CS to prevent conflicts (double booking)
on a calendar
The scenario is that a calendar could be marked for "allow no
conflicts", and the CS would automatically prevent this. This
might apply to direct booking or scheduling or both.
- How operational hours for a calendar are enforced
Each calendar MUST have a property for operational hours, and
CAP MUST specify how the CUA tells the CS to enforce those
operational hours. This means that the CS prevents components
from being added in a manner that violates the operational hours
set by the user. CAP MUST specify how policy enforcement can be
overridden by the owner of the calendar. CAP MUST specify
whether this includes alarms. This might apply to direct booking
or scheduling or both.
Open issue: Whether the ability to set a policy of turning down
requests that exceed a maximum duration (or length of time between
DTSTART and DTEND) is a requirement.
4.4.3 Deferred Requirements for Component Management
CAP is not required to specify:
- Undelete and purge deleted calendar entries.
- Modify inline attachment to URL; provide URL to fetch.
- Merge or aggregate more than one calendar.
- Lock access to calendar.
- Delayed or asynchronous transactions.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
14 Expires May 1998
- The CUA requesting a size limit before retrieving components
from the CS. The CS might send partial components if the
component's size exceeded the limit. CAP would permdit the CS to
refuse the request or give its preferred value.
- The CS synchronizing 2 calendars.
- How the CUA tells the CS to prevent conflicts with respect to an
individual component in the calendar. The scenario for this is that
a component could be marked for "allow no conflicts", and the CS
would automatically prevent a new component from being added in a
way which would cause a conflict. This might apply to either direct
booking or scheduling or both.
- How the CUA can create multiple entries on many CSs.
This may occur in one or more operations, perhaps using
different calendar protocols (CAP, iRIP, iMIP).
4.5 Lookup, Query and Discovery
Lookup includes the capability to list things. Querying enables
searching and filtering features. Discovery covers requests for
information such as what features are supported by the CS.
4.5.1 Lookup
CAP MUST specify, subject to access control:
- How the CUA can list calendars in a single CS, by fetching all
the top level CSIDs of the CS.
- How the CUA can list all the sub-calendars within a given
calendar.
- How the CUA can list all component UIDs in a calendar.
- How the CUA can retrieve all the free/busy data for a calendar.
- How the CUA can retrieve a list of properties for a component or
a set of components.
For this requirement, the set of components is defined either as
all the components in a calendar, or where the set of components
is defined by a search query (search query requirements are
elaborated in the Query Capabilities section). For example, the
CUA could ask for the DTSTART, DTEND and SUMMARY properties for
all components with DTSTART later than 9:00 p.m. today.
4.5.2 Query Capabilities
CAP MUST allow the CUA to retrieve CalIDs, component UIDs or
component hierarchical names (open issue) from a given calendar,
using queries which specify:
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
15 Expires May 1998
- How the CUA can retrieve data from multiple calendars.
This requirement allows the CUA to display multiple calendars to
the user. This requirement does not constrain this functionality
to a single request as it may be done in multiple requests.
- How the CUA to retrieve any named property for a calendar or
component.
For example, the CUA can retrieve the SUMMARY property for a
given component.
- Property value equivalence query (e.g., equal to)
For example, such as matching the organizer with a specified
user, or matching the location with a particular conference
room. This should work for all properties.
- Pattern-matching string comparison query (e.g., contains)
The pattern-matching query MUST be applied to a string property
such as a "name" property. The response MUST include a list of
calendar (or component) identifiers and MAY include property
values for those items. The CUA MUST be able to request which
properties (or the entire component) to retrieve.
- Property value comparison query (e.g., greater than, less than)
This requirement includes only those properties for which a
comparison query is possible. This list of properties MUST
include DTSTART, DTEND, DURATION. For example, this allows the
CUA to ask for all components that begin later than (greater
than) the specified time.
This requirement MUST be met in a way which allows the CUA to
discover which alarms will trigger in a given period.
- Multiple property value comparisons combined using Boolean
elements (e.g., logical and, logical or, negatation).
The CUA MUST be able to discover which components have durations
which occur at least partially in a given range of time, either
by retrieving the list of UIDs or by retrieving all of the
components properties. This requirement allows the CUA to
discover all components during a particular day or other time
period. This includes instantaneous and all-day calendar items.
This requirement does not state that the components MUST be
retrieved in their entirety in the same interaction as the
query; the query and the component retrieval can be separate
interactions between the CUA and the CS.
CAP MUST allow synchronization, meaning at a minimum that the CUA is
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
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
16 Expires May 1998
have been added, modified or deleted since it last synchronized, in
order to operate in disconnected mode. This requirement may be
satisfied using the query requirements already defined.
4.5.3 Specific Queries
These are specific scenarios required by calendaring operations which
may require special attention to ensure that they can be done with
the querying and lookup functionality of CAP.
CAP MUST allow, subject to access control:
- The CUA to retrieve the CSID for a calendar specified by giving
its hierarchical name, and vice versa.
This requirement means that hierarchical calendar names MUST be
unique on the CS.
Open Issue: This is an open issue.
- The CUA to discover conflicts given a list of calendars and a
time period
This feature is to allow the CUA to schedule a group of
attendees for a meeting at a particular time; the CUA MUST be
able to find out if those attendees are free at that time. This
requirement does not specify whether the discovery is done
mainly on the CS or on the CUA. For example, the CUA could ask
for the free/busy data for each calendar during the period and
then determine conflicts itself, or the CUA could ask the CS
which attendees have conflicts during the period. Either
approach would satisfy this requirement.
- The CUA to discover which calendar components need action.
iCalendar entries which need action include scheduled components
that have not yet been accepted or declined. The CUA needs to
know this list in order to present the items to the user to
resolve them.
4.5.4 Discovery
CAP MUST specify:
- How the CUA can query the calendar components which are
supported on a named calendar.
- How the CUA can query the names of all properties which exist on
a given calendar, or the properties which exist on a given
component.
- How the CUA can query the names of component properties
supported by a CS.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
17 Expires May 1998
- How the CUA can query the time zones supported by the CS
4.5.5 Deferred Requirements for Search
CAP is not required to specify:
- How to roll up free/busy information for a number of calendars
(perhaps sub-calendars) into a single free/busy component.
- How to fetch all components marked for deletion in a certain
range. This could include components somehow marked for deletion
but not yet purged from the CS.
- How the CUA can determine whether the CS supports multiple
reads/writes in the same operation.
This would include, for example, the ability to name a number of
calendars to add a component to in a single operation
4.6 Security
CAP MUST specify:
- How the CUA authenticates itself to the CS (not the calendar).
Authentication to the CS is required for all access to the CS.
The CS MUST be able to uniquely identify each user for the
purposes of authentication and authorization.
- How anonymous access to calendars is specified (if allowed).
- How the CUA authenticates to CS using SASL.
- How the CUA and the CS negotiate encryption mechanism for a
secure connection.
- How calendars can be made secure from unwanted access and false
entries.
- How the CUA and CS can specify denial of service to another
calendar user.
4.7 Designates and Delegation
CAP MUST specify, subject to access control:
- How a list of designates is created.
- How the CS knows that a user is a valid designate, through
authentication or some other mechanism.
- How the CUA can delegate to another calendar user.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
18 Expires May 1998
4.8 Notification (deferred)
There are no notification features that are required in CAP.
Notification is deemed not to be a requirement, because:
- A CUA can poll the CS for new/changed/deleted components,
including new ITIP messages. This functionality is needed to
support synchronization.
- A CUA can handle alarms on components itself.
The notification features that were considered but have been deferred
include:
- Notify the CUA when a change is made to a calendar.
- Notify the CUA when an alarm triggers.
- Notify the CUA when a calendar component NEEDS-ACTION.
- Notify when a CUA attempts to access a calendar, delete, modify,
or add a calendar component.
4.9 Access Control (deferred)
The ability to get and set access control data on calendars and
calendar components is useful, but beyond the scope of the initial
CAP specification. A CS may apply access control entries to calendars
and components, but CAP need not specify how these are to be set and
retrieved. Access control entries could be set and retrieved by
administrators on the CS through another protocol. Additionally, a CS
can enforce the class of each component, by restricting access to
"confidential" and "private" components, without any design in CAP to
allow this.
Access control requirements that were considered but have been
deferred include:
- CUA query the calendar access rights for the currently
authenticated calendar user.
- CUA grant/deny designate rights to a given calendar user.
- CUA removes OR denies all rights to a given calendar for given
calendar users.
- CUA grants free/busy view rights on a given calendar to a
calendar user.
- CUA grants full access rights on a given calendar to a calendar
user.
- CS performs calendar access rights inheritance on sub-calendars.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
19 Expires May 1998
- CUA grants/denies access rights to individual properties of
individual components.
For example, user A can see subject of event B, or user A can
set time of event B.
- CUA can set operation limits for user A on calendar B.
For example:
- (a) set time limit C on events for user D can schedule on my
calendar,
- (b) set limit number of events by user E, or
- (c) grant limited access on a calendar such that a user F can
only create events during specified hours.
4.10 Resource Groups and Pools (deferred)
A specification for how to handle resource groups and pools is not a
requirement. These kinds of features will be addressed in a separate,
later draft.
A group has a list of members, all of whom should be included in any
scheduled calendar component. For example, a group could contain a
particular conference room and a particular projector, both of which
should be scheduled for a meeting. Or a group could contain a number
of people working together, all of whom should be scheduled for group
meetings. When a group is included as an attendee, the CS MUST
schedule each of the members of the group.
A pool has a list of members, all of which are identical for the
purposes of scheduling, and only one of them should be scheduled.
When a pool is included as an attendee, the CS MUST schedule the
number of them that was requested. For example, a pool could contain
a number of VCRs, any of which can be scheduled for meetings, when
only one VCR is usually needed.
Resource group and pool features that were considered but were
deferred include:
- CUA can create a list of CSIDs which is a group or pool.
- CUA can request to add a component to every calendar for every
CSID in a group
- CUA can send a single schedule request to the CS, where the
attendee list includes a group. The CS then fans out the request.
Fanning out might be achieved by forwarding the request to all
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
multiple CSs.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
20 Expires May 1998
- CUA can schedule one CSID by scheduling one instance from a
pool.
- Each group/pool itself has properties.
- Access restrictions can be set on a group/pool, to restrict who
can get/set properties and who can schedule the group/pool.
4.11 CAP Non-requirements
CAP is not required to be:
- A client-to-client protocol.
- A server-to-server protocol.
For example, it would not specify how server-to-server updates
of calendaring or scheduling operations are accomplished.
The initial version of CAP is not required to specify:
- How to do a full administration CUA, e.g., add user, delete
user, move user, archive calendar, delete user, change
user/calendar name.
- Inheritance of calendar access rights, property values, etc.
5. Open Issues
Open issues include the following:
- Whether CAP should specify how clients can request their
connections to be kept open, and whether servers can drop
connections at any time.
- Whether calendars can also be referenced by their hierarchical
name.
- Is a particular optional feature (like fan-out, or calendar
access rights) supported?
- Determine what, if any, limitation the CS imposes on unbounded
recurrence rules.
- Whether CAP MUST support delayed operations and what that means,
and how results are returned.
- Whether all sub-calendars of a deleted calendar MUST be deleted.
- Whether the ability to set a policy of turning down requests
that exceed a maximum duration is a requirement.
- Whether expansion of recurrences is required.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
21 Expires May 1998
- Whether or not CAP operations support bounding the latency of
responses to operations.
6. Acknowledgments
The following have provided input in the drafting of this memo:
Lisa Lippert, Surendra Reddy, Richard Shusterman.
7. Bibliography
[ICAL] "Internet Calendaring and Scheduling Core Object Specification
- iCalendar", RFC 2445, November 1998,
http://www.ietf.org/rfc/rfc2445.txt.
[ITIP] "iCalendar Transport-Independent Interoperability Protocol [ITIP] "iCalendar Transport-Independent Interoperability Protocol
(ITIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ", (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ",
Internet-Draft, October 1997, RFC 2446, November 1998, http://www.ietf.org/rfc/rfc2446.txt.
http://www.imc.org/draft-ietf-calsch-itip-01.txt.
[IMIP] "iCalendar Message-based Interoperability Protocol (IMIP), [IMIP] "iCalendar Message-based Interoperability Protocol (iMIP), RFC
Internet-Draft, October 1997, 2447, November 1998, http://www.ietf.org/rfc/rfc2447.txt.
http://www.imc.org/draft-ietf-calsch-imip.
[IRIP] "iCalendar Message-based Interoperability Protocol (IRIP), [IRIP] "iCalendar Message-based Interoperability Protocol (iRIP),
Internet-Draft, October 1997, Internet-Draft, November 1998, , ftp://ftp.ietf.org/internet-
http://www.imc.org/draft-ietf-calsch-irip. drafts/draft-ietf-calsch-irip-02.txt.
7. Authors' Address 8. 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
VERSION:3.0
FN:Andre Courtemanche FN:Andre Courtemanche
N:Courtemanche;Andre
ORG:CS&T ORG:CS&T
ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R ADR;TYPE=WORK,POSTAL,PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R
3L5;Canada 3L5;Canada
TEL;WORK;MSG:+1-514-733-8500 TEL;TYPE=WORK,MSG:+1-514-733-8500
TEL;WORK;FAX:+1-514-733-8788 TEL;TYPE=WORK,FAX:+1-514-733-8788
EMAIL;INTERNET:andre@cst.ca EMAIL;TYPE=INTERNET:andre@cst.ca
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0
FN:Frank Dawson FN:Frank Dawson
N:Dawson;Frank
ORG:Lotus Development Corporation ORG:Lotus Development Corporation
ADR;WORK;POSTAL;PARCEL:;;6544 Battleford ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; Raleigh;
Drive;Raleigh;NC;27613-3502;USA NC;27613-3502;USA
TEL;WORK;MSG:+1-919-676-9515 TEL;TYPE=WORK,MSG:+1-617-693-8728
TEL;WORK;FAX:+1-919-676-9564 TEL;TYPE=WORK,FAX:+1-617-693-5552
EMAIL;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
22 Expires May 1998
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0
FN:Tony Small FN:Tony Small
N:Small;Tony
ORG:Microsoft Corporation ORG:Microsoft Corporation
ADR;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;WORK;MSG:+1-206-703-2190 TEL;TYPE=WORK,MSG:+1-206-703-2190
TEL;WORK;FAX:+1-206-936-7329 TEL;TYPE=WORK,FAX:+1-206-936-7329
EMAIL;INTERNET:tonysm@Microsoft.com EMAIL;TYPE=INTERNET:tonysm@Microsoft.com
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0
FN:Steve Mansour FN:Steve Mansour
N:Mansour;Steve
ORG:Netscape Communications Corporation ORG:Netscape Communications Corporation
ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain
View;CA;94043;USA View;CA;94043;USA
TEL;WORK;MSG:+1-650-937-2378 TEL;TYPE=WORK,MSG:+1-650-937-2378
TEL;WORK;FAX:+1-650-937-2103 TEL;TYPE=WORK,FAX:+1-650-937-2103
EMAIL;INTERNET:sman@netscape.com EMAIL;TYPE=INTERNET:sman@netscape.com
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0
FN:Peter O'Leary FN:Peter O'Leary
N:O'Leary;Peter
ORG:Amplitude Software Corp. ORG:Amplitude Software Corp.
ADR;WORK;POSTAL;PARCEL:;;185 Berry St. Suite 4700; San Francisco;CA; ADR;TYPE=WORK,POSTAL,PARCEL:;;185 Berry St. Suite 4700; San
94107;USA Francisco;CA;94107;USA
TEL;WORK;MSG:+1-415-659-3511 TEL;TYPE=WORK,MSG:+1-415-659-3511
TEL;WORK;FAX:+1-415-659-0006 TEL;TYPE=WORK,FAX:+1-415-659-0006
EMAIL;INTERNET:poleary@amplitude.com EMAIL;TYPE=INTERNET:poleary@amplitude.com
END:VCARD
BEGIN:VCARD
VERSION:3.0
FN:Doug Royer
N:Royer;Doug
ORG:Sun Microsystems
ADR;TYPE=WORK,POSTAL,PARCEL:;;901 San Antonio Road, MS MPK17-105;
Palo Alto;CA;94303;USA
TEL;TYPE=WORK,MSG:+1-650-786-7599
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 chairman of that working group is: and scheduling Working Group. The chairmen of that working group are:
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
23 Expires May 1998
FN:Anik Ganguly FN:Anik Ganguly
N:Ganguly;Anik
ORG:Open Text, Inc. ORG:Open Text, Inc.
ADR;WORK;POSTAL;PARCEL:;;38777 West Six Mile Road Suite 101; ADR;TYPE=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 Livonia;MI;48152;USA
TEL;WORK;MSG:+1-734-542-5955 TEL;TYPE=WORK,MSG:+1-734-542-5955
EMAIL;INTERNET:ganguly@acm.org EMAIL;TYPE=INTERNET:ganguly@acm.org
END:VCARD END:VCARD
BEGIN:VCARD
VERSION:3.0
FN:Robert Moskowitz
N:Moskowitz;Robert
EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com
END:VCARD
9. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process MUST be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Courtemanche,Dawson,Mansour,O'Leary,Royer,Small
24 Expires May 1998
 End of changes. 142 change blocks. 
238 lines changed or deleted 1066 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/