Notes from CSG Meeting

• March 28, 2003 Conference Call
• CSG Attending: Tracy, Oren, Paul
• OSAF Attending: Katie, Chao, Ducky

Before the meeting, we had written up some initial scenarios and questions in preparation for the meeting.

10,000 ft overview

Four scenarios emerged:

• 1. Chandler workgroup calendaring. Chandler relay servers for sharing and availability. No centrally managed server, with its attendant administrative features. Minimal interoperability with Corporate Time or other "enterprise" solutions (perhaps meeting invitations and responses via email without free-busy time -- iTIP/iMIP).

• 2. Chandler as a CAP client to a CAP server (Corporate Time, Sun One, UW Calendar Server or others.) Chandler treats CAP in a similar manner to IMAP. Interoperability between Chandler workgroup calendaring (no CAP server involved) and people using full CAP solutions (Corporate Time or otherwise) is minimal. Any user running Chandler as a CAP client has full interoperability with other CAP users.

• 3. Chandler workgroup calendaring implements full CAP interoperability.

• 4. Chandler implements a calendar server. The features that distinguish this scenario from the first scenario in principle are the administration features that allow someone to manage Chandler servers centrally.

Comments on the scenarios

The big schools with Corporate Time deployments (or other big deployments) are be unlikely to be interested in the first scenario. They might actually discourage people from using Chandler for calendaring, because they want everyone to work and play well with the solution they've invested so much energy in.

Small departments might be interested in the first scenario, as an alternative to Meeting Maker or Exchange. This scenario will only apply to a smallish subset of possible university users. A workgroup might be around 50 people, but they will want to "interoperate" with other workgroups. By "interoperate", we mean that they will want to invite each other to meetings, and to view each other's free-busy time.

The second and third scenarios are more appealing, as they allow folks to try out Chandler without displacing their investment in Corporate Time or other solution. The best case would be if Corporate Time and other servers supported CAP. If not, working with the Corporate APIs directly is not a terrible solution for folks with Corporate Time, although its less appealing to OSAF.

The fourth scenario would be appealing in theory, but everyone recognizes that it could only be available as a "test" scenario in the Westwood timeframe. It would be more interesting (w/respect to calendaring) to have scenarios 2 or 3 as a path to this scenario, deployable in a reasonable time frame.

CAP is a big motivator, folks would like to encourage standards and build momentum around CAP. There's a reasonable chance that Corporate Time will support CAP, although there's some risk that it will do so in a reasonable time frame. There's some risk that Oracle will make Corporate Time more like Exchange, and that it will become less appealing to universities. OSAF will try to contact the Corporate Time folks directly to help evaluate the risks. The Corporate Time folks showed up and participated at the recent IETF conference, which was a good sign.

The admin features are what distinguish the last scenario from the first scenario, not scalability per se. Scalability is desirable even in the first scenario. In particular, if lots of workgroups are running Chandler, a given user will want to be able to schedule meetings with anyone using Chandler, not just folks in the workgroup.

Requirements

Delegation

• Delegation features are critical. Large numbers of folks who use the group calendaring systems do so for delegation features. Delegation features would be critical for adoption.
• Key implementation issues:
  • Providing the right access control might be good enough.
  • Paul described a more sophisticated model, where folks are authenticated as a "designate" identity. Unfortunately, no good ui examples for this model, but would be cool if we could figure one out.
• Access requirements might depend on time sensitive roles. Use case: someone on the ER shift has access while on shift, not all the time.
• Corporate Time forces you to log in separately if you are a "designate" for different calendars, but you want to see the data all in one view.

PDA support

• PDA syncronization (e.g. Palm conduits) would be good enough for a first release. Ideally, folks would be interested in a first class PDA client.
• Palm and Pocket PC are both used.

Web access

• For a Canoga-style workgroup solution, some form of Web access will be critical to some campuses. Campuses are pushing "information portals" and would want calendar information.
  • APIs for folks to access the calendar information to write a web client or add to the portal solution might be good enough for a first release.
• If Chandler is a CAP client to a Corporate Time server, as an example, web access is less important, because Corporate Time already provides the functionality.

Resource scheduling

• Outlook-style room scheduling (e.g. conference rooms and projectors) is good enough, Chandler is not going to attempt a full scale reservation system. Chandler is also not going to attempt a full scale scheduling application (i.e. university wide course scheduling).

Event Calendaring

• This is a big hole in current product offerings. Universities are interested in publishing event calendars to the wide university audience, and even to the public in general. Right now they cobble together home grown solutions, usually data on web pages. You really want this data available as iCalendar data, and you want to be able to pull it into your personal calendar.
• UW's web based calendaring system addresses event calendaring (they have a good set of requirements).

Groups

• For managing delegation-designation correctly, resource management, access rights, etc. you want strong support for groups.
• Use case: Schedule a recurring meeting with all administrators. Dynamically do the right thing if 3 months later the group changes: new administrators or some administrators leave. The next meeting should involve the current set of administrators, not the original list.

Action Items

• Katie will prepare a second round proposal based on this feedback and other feedback, in a couple of weeks.
• Chao will start scheduling the next meeting to review this proposal.
• Katie will schedule a meeting with Paul and Oren to go over some technical questions.
• Chao will follow up on resolving twiki access issues.
• Katie will prepare the twiki to get feedback from Tracy, Paul and Oren on individual features.
• Tracy, Paul and Oren will give feedback on individual features. They can edit the twiki directly, or they can send Katie email and she will update the twiki.
• Pieter (not at the meeting) will follow up with Corporate Time contacts (given to us by Jeff McCullough) to understand where they are going with CAP (and when).

-- KatieCappsParlante - 31 Mar 2003