[Ietf-caldav] freebusy lookups in CalDav are too hard to consume?

[Cyrus Daboo]

Hi,
I am going to try and address several of the comments in this thread in one 
go.

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 
it...

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 
mobile devices).

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 
shifted.

Summary:

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 
too: <http://www.calconnect.org/publications/caldavusecasesv1.0.pdf>.

I suspect there is still plenty more to discuss on this topic...

-- 
Cyrus Daboo