Meeting Notes

• 2 April 2003
• OSAF attending: Katie, Aleks
• CSG attending: Paul, Oren
• We had a conference call to discuss CAP and architecture topics that we didn't get to at the previous meeting.

User Calendar Discovery

• Its the CUA's responsibility for connecting to the right calendar store. (Instead of deferring to the calendar store, fanning out the responsibility.)
• The calendar server is identified by the csid in the capurl
  • "cap://cal.example.com/Company/Holidays" => csid is cal.example.com
• The CUA uses some out of band method to discover a user's capurl, just like knowing an email address.
• RFC2739 (Locating a Calendar User) was an attempt to address this question, interesting to look at.

Multiple Repositories (CAP, Chandler, IMAP, other)

• Given a user, or a calendar, or an item in the calendar, how does Chandler know what's the calendar store of record?
• Scenario: an individual user stores their personal calendar on their local machine. They have a "meetings" calendar on a CAP store, by mandate from the university. The "meeting room" calendar is on some other CAP store. The user wants a seamless picture of all of these repositories.
  • The chandler user should be able to view any of the repositories
  • The chandler user should be able to view multiple calendars, from multiple repositories, at the same time.
  • The chandler user might have a "cache" of calendar entries from a CAP store on their local machine. Perhaps the CAP store removes last year's data, and the local user wants to keep old data this way. Its not really a cache in this case, but "downloaded" into their local Chandler repository.
• Paul mentioned his writeup on IMAP integration, which is in line with our thinking and relevant to CAP integration as well: Paul Hill's comments and proposal on IMAP integration.
• One can imagine that we need to track meta-information about the repository that an item belongs to. Looks like we'll need to do it at the attribute level as well.

Publishing, sharing calendars

• Keep in mind the different ways of managing calendars: shared calendar model, subscription model, etc.
• Generally, managed with read/write access to other repositories.
  • One alternative: iMIP (email)
  • Another alternative: iTIP pushing of data instead of allowing read access to your calendar
• Some of the functionality was added for very stringent security requirements, use cases
  • In particular the complicated VCARs for visibility.
  • e.g. the cia doesn't want folks to know who else was invited to a meeting

Designation/delegation

• IDENTITY command will likely be removed from CAP. It was intended for efficient server to server communication, so that commands could be executed with different identities on one connection. It was not intended for the designate/delegation use case.
• SASL: user authenticates, then assert optional authorization id
  • e.g. An admin logs in on their own account, then asserts that they are "acting on behalf of" the provost
  • allows clear audit history
  • in theory supported, haven't seen any uis with this feature yet
  • This is the direction CSG folks would like to go, but not a showstopper requirement for the first release
• Designation behavior can be achieved with a combination of appropriate access control, use of mailing list
  • e.g. An admin logs in on their own account. The admin has access to the provost's calendar data. A mailing list is set up so that when someone requests a meeting with the provost, both the provost and the admin get email. The reply will be either from the admin or the provost directly.
  • This kind of approach would likely suffice for a first release, its what people do today.
  • The good part about this approach is that the admin does not have to "pretend" to be the provost and know the provost's password, that would be the worst approach.

Notification

• CUA's responsibility to query the server, no notification mechanism in the standard. (Not in the CAP charter, by design)
• Interesting conversations on the topic in the hallways at the latest IETF conference.

Free-busy

• If RAP supports a query mechanism where I can query for the right subset of information, and only pick up the attributes I want per item from the result set, then that addresses his concern about free-busy requests being network efficient.
• The query language is a big part of the semantics of RAP and needs to get fleshed out.

-- KatieCappsParlante - 02 Apr 2003