Calendar Proposal for Westwood [DRAFT]

Introduction

Chandler's first release, Canoga, will include individual and group calendaring features as one element of a more general personal information manager (PIM). We find these aspects of the Chandler calendar particularly compelling:

• Inspired by the products Agenda and Ecco, calendar data and calendar views will be part of a flexible general information management system. In Chandler terminology, calendar data (events and tasks) will be represented as "items" with "attributes" and stored in the Chandler repository along with other PIM "items", including contacts, emails and notes. Calendar items might have both calendar specific attributes, e.g. "start time" and "location", as well as general attributes that any item is likely to have, e.g. "project" or "last modified date". In addition to the traditional day, week, and month views, calendar items can be viewed in general purpose outline or table views along with other PIM items: a "project" view may display emails, notes, events and tasks in the same view. Additionally, the calendar views can be used to view other types of items. A user might create a custom view where email items are displayed in a month view, based on the date of the email. All of the features planned for Chandler items in general will be available for calendar items, including data sharing, custom views, filtering, fast searching, smart parsing, etc.

• Chandler will offer "serverless" group calendaring for small workgroups. We do not necessarily mean that workgroups will not use any servers, but that a 100 person workgroup would not have to hire an administrator to run a special server to use group calendaring. Users will be able to share calendar information, invite others to meetings, etc. By publishing calendar data to a common "relay" server, which is just another instance of Chandler that remains available. A Chandler user would be able to invite any other Chandler user to a meeting, whether or not the users are in the same workgroup, as long as the Chandler users can access each other's repositories.

• Chandler will use IETF calendaring standards for interoperability. Chandler will be able to publish or subscribe to iCalendar data, and to use iTIP/iMIP for meeting invitations and responses.

Chandler's second release, Westwood, will include all of the Canoga features and will add features to support the needs of universities. In particular:

• Chandler will be a standards based CAP client. While universities do sometimes have small departmental workgroups who might like to run a decentralized calendar solution, universities also have the need for a centrally managed calendar. If a university runs a CAP server to manage such a calendaring system, Chandler can run as a client to that system. This solution allows the university to provide different kinds of access to the calendar data, including Chandler, web access, and/or any other CAP client.

• Chandler will include calendaring features of special importance to universities (features that might not be as important to small workgroups.) In particular, Chandler will include designation and resource scheduling features in Westwood.

• Chandler will support a kiosk mode to facilitate the needs of nomadic campus users.

This proposal will discuss the Westwood features in more detail.

Westwood Calendar Deployment Scenarios

For Westwood, Chandler will support two different modes of operation, which we'll call the workgroup scenario and the CAP client scenario. The workgroup scenario involves the Canoga "serverless" calendaring or low-administration calendaring features. The CAP client scenario involves Chandler using open standards to act as a calendar client (or calendar user agent) to a centrally administered CAP calendar store.

OSAF also has plans in future releases for two other scenarios : full CAP interoperability, so that workgroup users can interoperate with any CAP users, and Chandler as a full CAP server.

These four scenarios are described in more detail below.

Workgroup Scenario

In the workgroup scenario, a Chandler user's data is stored on the user's local repository. The Chandler client talks to the local repository using Chandler's RAP protocol. The RAP protocol is a general "item" protocol, the same protocol is used for all of Chandler's PIM data.

A Chandler client uses the same protocol to browse or search a remote Chandler repository. In the case of the calendar, the protocol can be used to view free-busy time in another user's repository. As Chandler users might not keep their computers on all of the time, a Chandler user may choose to replicate all or part of their repository on another server that is on all of the time (a "relay" server -- the "workgroup PC" in the diagram below). A workgroup may choose to run one machine as a relay server, for all users in the workgroup to publish shared data. For calendar data in particular, free-busy time would be shared to this relay server. The repository replication features might also be used to synchronize a Chandler user's repository on two machines, for example a home and a work machine.

A special mention should be made about how Chandler will handle meeting scheduling.

• Free-busy data is either an attribute on an event item, or is an item in its own right. Either way, free-busy time can be queried and read in the same manner as all other Chandler data. Special care will be taken such that free-busy time can be queried without fetching other extraneous data, as these requests will be particularly common for scheduling purposes. In general, RAP can fetch "partial" items from the repository: RAP can fetch a subset of an item's attributes, to reduce network traffic.

• Chandler meeting requests and responses will be stored as "items", similar to iTIP objects. We expect to have a lossless mapping between our calendar items and iCalendar data, this includes iTIP objects. The meeting request and response items will be stored, queried, etc. using RAP, just like all other Chandler items. The Chandler client is responsible for interpreting these requests and handling them accordingly. This architecture will facilitate interoperability with both iMIP and CAP: the Chandler client will behave similarly whether a meeting request arrived via email or through the repository.

OSAF understands that universities have a history of using workgroup solutions and trying to scale them over many decentralized groups across the university. The Chandler workgroup solution for Westwood needs to support scaling in this fashion. One use case particular to calendaring: if many departments are running Chandler in the workgroup scenario, they would expect to be able to invite people from other departments (workgroups) to meetings using free-busy information, without the system breaking down.

Chandler as a CAP Client Scenario

While the workgroup solution uses calendaring standards (iCalendar, iMIP, iTIP), it uses RAP as the protocol between client and calendar store. For Westwood, we'd like to extend Chandler's support for calendaring standards to include CAP.

In this scenario, a Chandler user's calendar data is stored on a CAP server. The CAP server would be provided by a third party: UW, Oracle and Sun have been mentioned as possible providers of CAP servers.

Chandler might "replicate" all or part of the calendar data into the Chandler user's local repository. This replication would provide some benefits: (1) long term storage if the CAP server has a quota on the user's data, (2) deep integration between calendar data and other types of data in the Chandler client, (3) access to data when offline. The calendar's local repository will have meta-data to know what items and attributes are "cached" from a CAP calendar store and what items and attributes are "local" to the Chandler repository.

The Chandler client's item viewers might be aware of different repositories (local vs. a remote CAP repository), but the items and attributes appear to be the same to the Chandler client's item viewers. This architecture allows some interoperability between calendar data in a Chandler repository and calendar data stored on a calendar server.

A use case to illustrate the CAP client scenario:

• A teaching assistant in the computer science department uses Chandler to manage several calendars. The teaching assistant is also the organizer of an intramural ultimate frisbee team. The computer science department maintains a CAP server, course schedules and all departmental meetings are managed on the CAP server. The TA has a calendar store on the CAP server, and uses Chandler as a CAP client to schedule meetings with other TAs and professors, who also have calendar stores on the CAP server. The TA runs a computer in their dorm room that acts as the "frisbee" calendar relay server, the TA is running an instance of Chandler on that machine.
  • The TA can view all of the calendar data in one view in Chandler.
  • The TA can invite any of the other cs department folks to meetings, and vice versa.
  • The TA can invite any of the other frisbee folks to meetings, and vice versa.
  • The frisbee folks can see the TA's free-busy time, and the cs department folks can see the TA's free-busy time, but only if the TA sets up Chandler to replicate free-busy time to both "servers".
  • The other cs department users and the frisbee users cannot view each others' free busy time, because Chandler will not support full CAP interoperability in the Westwood timeframe.

Full CAP Interoperability Scenario

To support full CAP interoperability, the Chandler repository would have to support the CAP server interface. In this scenario, any CAP CUA could schedule meetings using free-busy information with any Chandler user (as long as the permissions were ok), and vice-versa.

While Chandler will not support this functionality in the Westwood timeframe, we are cognizant of this scenario as we're creating the Chandler architecture.

In general, Chandler's relationship to CAP has some similarity to its relationship to IMAP and LDAP. We'd like the Chandler architecture to support multiple data sources.

Chandler as a CAP Server Scenario

In the long term, OSAF envisions creating a full server version of the Chandler repository. A full server version would need to include administration features, and would generally need to support a full university deployment. When Chandler offers a full server version of the repository, we'd like to be able to provide CAP server access to the calendar data.

Highlighted Features for Westwood

A more complete list of the calendaring features for Canoga and Westwood can be found here: Higher Ed Calendar Requirements. This section addresses a few of the features that are particularly interesting to universities.

iTIP/iMIP scheduling

Westwood will support iTIP/iMIP scheduling, where meeting invitations and responses are sent via email. Because email is used as the transport for meeting scheduling, the user does not have access to free-busy time information about the other users when this protocol is used. iTIP/iMIP scheduling will provide for some degree of interoperability with other email clients.

Designation features

Westwood will support calendar designation features. (Sometimes these features are called "delegation" features). The user scenario we have in mind here:

• A busy CIO has hired an administrative assistant to manage her meetings for her. The assistant has permissions to read and write to the CIO's "work" calendar. The assistant gets a copy of all schedule related notifications (invitations and responses). When the assistant sends a schedule related request (an invitation or a response), it is clearly marked as "on behalf of" the CIO. The assistant never has to "pretend" to be the CIO by logging in as the CIO or knowing the CIO's password.

Although we don't yet have a complete design for the user interface of these features, we are assuming functionality similar to Corporate Time's designation features, or Outlook's delegation features.

Designation features have some interesting implementation issues, related to security. For Westwood, Chandler will implement these features using groups and permissions. A use case to illustrate:

• An administrative assistant is scheduling a meeting for the CIO. The administrative assistant needs to see the free-busy time for all of the potential meeting attendees. This means that the administrative assistant needs read access to the free-busy time of all of the meeting attendees. The administrative assistant has these permissions because the administrative assistant and the CIO are in the same "group" that has been granted these permissions.

One could imagine the scenario above being handled differently, where the administrative assistant is granted the correct permissions while acting "on behalf of" the CIO, via some complicated rights delegation scheme. We understant that SASL can help facilitate this scheme: after a user authenticates, they can assert an optional authorization id to "act on behalf of" someone else. While Chandler may do this in a later release, we're not planning on doing full rights delegation for Westwood.

Handheld synchronization (Palm and Pocket PC)

Westwood will include synchronization with Palms and Pocket PC's for calendar events and tasks, we understand this is a must-have feature for universities.

In the long term, we'd really like to write a version of Chandler tailored specifically to handheld devices. One could imagine this client accessing a remote repository wirelessly, and/or having a local repository specifically designed for the device. Although we're not planning on doing this for Canoga or Westwood, we're considering this scenario when making architectural decisions.

Resource scheduling

Westwood will support basic resource scheduling as part of its group calendaring features. Meeting rooms and projectors are examples of resources. Westwood will not provide a full reservation solution, but it will provide features on par with Outlook and Corporate Time.

Web access

Although our full plan for Chandler includes full access to calendar functionality from the web, we're not implementing a web application for Canoga or Westwood. We understand that web access is very compelling to nomadic users in universities. Two possible solutions:

• As Chandler will be a CAP client, universities can provide web access through their CAP server. The CAP server providers that have been discussed (UW, Oracle, Sun) will all provide web applications for browser access to calendars.
• Chandler is open source, will have well documented APIs, and will make use of IETF standards where possible. Calendar data will be available from the repository as iCalendar data, for example. Individual universities are welcome to write web applications to access this data. OSAF will do what it can to support these kinds of efforts.

Groups

We plan on having strong support for Groups in Chandler, and we understand that group features are important for calendaring features.

An example of a use case that we'd like to get right:

• An administrative assistant would like to schedule a recurring monthly meeting for all of the administrators on campus. When a new administrator is hired or retires, the administrative assistant adds or removes the person from the "administrators" group. The next meeting that occurs should involve the current set of administrators, not the set of administrators that existed when the meeting was created.

As mentioned above, good group support also helps facilitate the designate use cases. In general, groups are very important to data sharing and security features, as discussed in Data Sharing in Canoga.

Event Calendaring

While Westwood will not be a first class event calendaring application, Westwood will have some features that help support event calendaring. Westwood users will be able to "publish" an iCalendar calendar to a server via Trash.WebDAV, as does Apple's calendar application. Westwood will also be able to "subscribe" to an iCalendar on a Trash.WebDAV server. More generally, calendar data created with a Chandler client and stored in a Chandler repository will be available as iCalendar data. An illustrative use case:

• A student can download a course schedule from a website, published by the department hosting the course. The course schedule is stored as iCalendar data. The calendar is imported into the student's Chandler client. The course schedule may have been created by the department's administrative assistant using Chandler, or it may have been created using some other application, as long as its iCalendar data.

Freebusy

Westwood users will be able to view each other's free-busy time, if they choose to publish that information. For users using Westwood's workgroup solution to publish free-busy time (instead of using a CAP calendar store), the workgroup would run a separate instance of Chandler as a "relay server" for highly available shared information. Like a departmental file server, this machine would be administered locally, and remain turned on and on the network. Individual users can "replicate" their free-busy time and other shared information from their local repository to the repository on the "relay server". A user can then view shared information from the repository on the "relay server", as long as the user has the right permissions.

As most of the calendar-related traffic in the workgroup setting concerns sharing this free-busy time to view as users schedule meetings. A Chandler client uses the RAP protocol to fetch this information. Its important that the Chandler client be able to fetch just free busy information (not all information associated with an event) and be able to fetch information for a particular time period (not for all events in the calendar). Using RAP, the client makes a query to fetch items from the item store. RAP allows the client to specify the "attributes" of the items to be fetched. The query language will support the free-busy time request use case, allowing the client to fetch items from a particular calendar, in a particular date range.

Oracle Calendar (Corporate Time) interoperability

Our primary strategy for addressing interoperability is through IETF calendaring standards. For Westwood, Chandler will be a CAP client. Oracle has publicly stated that Oracle Calendar will support a CAP server in a future release. We are in ongoing discussions with Oracle about standards based solutions for calendar interoperability.

-- KatieCappsParlante - 09 Apr 2003