Calendar & Scheduling Working Group minutes, Wed Nov 20 reported by Larry Greenfield Bob Mahoney is chairing. . Chair, introduction & aenda bashing . Chair, status of drafts CAP is very long lived and still changing. More eyeballs are needed and encouraged! xCal has been in and out of the working group. We didn't want to get distracted from our major goal (CAP) but maybe it's possible for us to do work on xCal without getting too distracted. . Chair, interop results Novell intended to hold a physical interop, but not enough participants would have been able to come. Instead a virtual interop was held with IBM/Lotus, Oracle/Steltor, Novell, and KOrganizer participating: exchanging calendar objects and participating in conference calls. We need a better feature matrix if we want to move iCal to draft; anyone interested in doing so should volunteer. . Chair, point of information There's a Java iCal parser at http://www.sourceforge.net/project/jical/. . Pekka Pessi, iTIP SIP binding "iSIP" draft-pessi-calsch-isip-00.txt iSIP currently uses xCal ("it seemed like a good idea at the time") but the iCal format might actually be more extendable and more suited for our purposes. iSIP doesn't conflict with the current calsch work. Should it be part of calsch? What interesting applications are enabled by iSIP? The chair pointed out that the WG is already way overdue on some milestones so it might not be that wise to take more stuff on. Paul Hill asked why this wasn't being done in SIPPING; Pekka replied that SIPPING is very crowded and has many requirements and the calendar expertise is here. Aki Niemi thought that SIPPING had shown some interest. Chris Newman pointed out that there needs to be applicability of when to use iSIP instead of or in addition to iMIP and iRIP. . Chair, mailing list The mailing list can seem unfriendly or imposing but don't let us old bitter people scare you. Please participate! . Chris Newman, some issues with CAP Issue #1: How are calendars named and how do clients discover calendars available. Clients need to be able to find out what calendars it can access: private, shared, and public calendars. Larry Greenfield and Paul Hill discussed that this was brought up some time ago, and Paul talked about how the various subscription models of the calendars can be fairly confusing. Disagreements about what the namespace is makes coming to consensus hard. Chris pointed out that the mailbox namespace is one of the worst parts of IMAP interoperability, and committed himself to drawing an analogy between IMAP and CAP namespace on the mailing list. Issue #2: What should the mandatory to implement security be? Chris recommends requiring implementations support TLS with the SASL mechanism PLAIN, since it deploys much better than DIGEST-MD5. Kurt Zeilenga agrees. Issue #3: Multiple connections versus BEEP channels. The current draft doesn't discuss whether servers have to process channels in parallel or if processing on one channel can block the other channels. If clients only make a single TCP connection, rate limiting and other accounting is much easier---but if clients have to open multiple connections to keep long running operations from blocking, they will. Larry Greenfield said that requiring parallel processing of channels is a barrier to implementation and it isn't clear how to write an on-the-wire specification requiring it. Some discussion on Jabber with Marshall Rose and Larry Greenfield. Patrick Falstrom said that understanding congestion control/resource allocation on the application layer is a general concern for the IETF but no one has any good ideas. Issue #4: Round trips are very expensive; pipelining should be mandatory. . meeting adjourns