[Ietf-caldav] freebusy lookups in CalDav are too hard to consume?
cyrus at daboo.name
Fri Jun 2 08:39:04 PDT 2006
I am going to try and address several of the comments in this thread in one
1. httpclient/webdavclient libraries etc:
FYI Last year I built a caldav client library using httpclient and the
slide client library together with my own iCal library. It was trivial to
do (though I knew enough about iCalendar in the first place). WRT slide
library not having been updated in a while - yes that is true but it seems
to work fine - and its open source so you can always contribute. As to
Legal - of course one has to go through that for every piece of open source
software at least once...
2. Using a simple GET request for free-busy:
The example given is not as simple as it first seems: there is still work
you have to do to at the very least to parse and understand the date/period
format and know what 'BUSY-TENTATIVE' etc means. i.e. the semantics of
calendars still have to be understood no matter what syntax or protocol is
used to transport the data.
Certainly if all you want is a free-busy view of a single calendar, the GET
approach is trivial and easy. But the reality is there is much more to
calendaring than just that.
Lets be clear, the free-busy report in CalDAV access is not really useful
when it comes to doing free busy lookups of calendar USERS as opposed to
just looking at a static calendar. The actual need is to target calendar
users (who may have more than one calendar contributing to their free
busy). The CalDAV schedule specification, a new version of which was
published to internet-drafts last week, addresses this by allowing iTIP
free busy requests targeted at one (or more) local (or possibly remote)
users on a CalDAV server. This returns a much more useful response listing
each user's f-b info. It also deals with the issue of how to grant someone
the right to only see free busy and not the entire calendar data.
3. REPORT method and firewalls:
Any organization that has gone to the trouble to setup a firewall (be it
one that allows WebDAV methods or not) will likely require all external
users to use SSL when connecting from outside when accessing company
sensitive information such as email and calendars. So ssl (https) will
almost certainly be a requirement for CalDAV use and that, as others have
pointed out, pretty much gets around any firewall problems.
4. Make REPORTs optional:
The reports are a key part of CalDAV, if you make them optional then you
might just as well do plain WebDAV (e.g. GroupDAV) or HTTP. They are
certainly not trivial to implement (well multiget is actually pretty easy)
but most of the complexity is tied up in the calendar data semantics. For
example, a time-range query seems simple at first glance, but when you take
into account all possibilities allowed by iCalendar (timed, all-day,
floating, timezones, recurrences, events with a start only, to-do's with
due only etc) it gets complicated. We spent a fair bit of time putting
together the tables describing how that works for the different components
in the hope that would save implementers a lot of time.
5. iCalendar vs XML syntax:
We did design CalDAV in such a way that an XML-representation of iCalendar
data could be used at some point in the future in a backwards compatible
manner once one has been standardized. It certainly seems like
standardizing that should be the first step to the simple GET approach and
to CalATOM etc. Someone needs to pick up that effort again and run with
People have pointed to some benefits of XML syntax, including XPath/XQuery.
But again, those do not address the semantics of calendaring. The most
common query that is likely to used in calendaring is a time-range query.
XPath/XQuery would have to be extended with a special 'timerange' test
function for that to work properly with recurrences, floating time etc -
another syntax does not hide the complexity of the semantics.
In any case, I do think having an xml syntax a useful thing to have, but
its going to have to live alongside iCalendar for a long time to come
because iCalendar is already widely deployed and used. Upgrading/changing
data formats takes a very long time to do - don't forget there are still
many implementations using the older vCalendar spec even today (e.g. many
6. xslt on free-busy:
I'm not an xslt expert, but would welcome comment from others who are.
However, I do question whether a simple transformation is enough. For
example, the user would almost certainly want to see the UTC-relative
free-busy times shifted to their local timezone (or the timezone in which
they are planning the meeting) so the xslt transform would need to apply
timezone/dst rules. Of course you could push the timezone offset
calculation off to the server and have the returned free-busy times already
At first glance having a simple free-busy lookup via GET sounds like a
great idea, but when you look at real use cases and constraints its going
to be a lot harder than originally proposed. Of course it can be done, but
by the time you've finished addressing the real-world use cases you may
well end up with something just as 'hard' to do as the CalDAV equivalent.
If people want to pursue this then I encourage you to write up the actual
use cases that need to be addressed and then see what needs to be done. You
might want to take a look at some of the use cases that Calconnect produced
I suspect there is still plenty more to discuss on this topic...
More information about the Ietf-caldav