[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minutes from Wednesday's meeting
Calendar & Scheduling Working Group minutes, Wed Nov 20
reported by Larry Greenfield <leg+@xxxxxxxxxxxxxx>
Bob Mahoney is chairing.
. Chair, introduction & agenda 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
We need a better feature matrix if we want to move iCal to draft;
anyone interested in doing so should volunteer. Drop a note to the
chairs if you would like info on how to help.
. Chair, point of information
There's a Java iCal parser at
. Pekka Pessi, iTIP SIP binding "iSIP"
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
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
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
. meeting adjourns