[Ietf-caldav] freebusy lookups in CalDav are too hard to consume?
robyates70 at gmail.com
Fri Jun 2 19:19:49 PDT 2006
I agree with a lot of what you write here, but not your conclusions :)
Yes, it is possible to work around all these things by doing more work
and sometimes a lot more work. I just have to ask why? What is special
about freebusy lookups that mean that they can't be accomplished in a
manner that is more widely adopted and that most application developers
are very familiar with.
The proposed GET matched the functionality of the CalDav freebusy report
and so direct comparisons of development effort, testabilty,
consumability and deployment can be made, and I still maintain that the
effort will be substantially reduced for GET. However, below you seem to
be arguing that the CalDav report is "not really useful" and go on to
state that more functionality is required and hence GET is not that
simple. I am not really following your argument. If the freebusy report
in CalDav is useful then it can be accomplished in a simpler manner with
a GET. If it is not that useful and something else is needed then we
should look at what that is and also see if it is easier to consume,
develop, test etc. using a GET vs. REPORT.
Finally, if the freebusy report in CalDav really is not that useful then
shouldn't it be an optional report, instead of a mandated one?
more comments below.
Cyrus Daboo wrote:
> 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...
I agree with this, but as a product manager releasing a piece of
software, would you want it to depend on a library that doesn't appear
to have much momentum behind it (not having been updated since 2004) and
that in turn depends on a jar file that has been end of life'd?
> 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.
agreed, but this is nothing to do with the use of http GET vs. webdav
> 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.
Am confused by what you are saying here. The GET that I described could
have the same functional semantics as the REPORT, namely that it would
be possible to pass in the same parameters and get the same response.
Are you stating that the REPORT as described in CalDav is not that
useful? and if so, why is it mandatory?
> 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
Just to be clear the firewall issue is not only applicable to access
originating from outside the company's intranet. It applies equally to
an end user sat on the corporate network accessing their corporate
servers. As we consider using PUT and DELETE methods in our products we
are surveying clients infrastructure to see if it is viable. The early
results are mixed and it looks likely that we will require a means to
tunnel PUT and DELETE over POST, at least for the short term. We are not
presently surveying for the REPORT method but I would guess it would
produce a similar, if not worse, set of results. SSL is also no magic
bullet here as is dramatically effects the throughput that can be
achieved on any given server. Most of our customers are not eager to
have it turned on for every single server request.
> 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.
Again, I find myself in violent agreement :). It is hard to do the
time-range queries and yes they are a key part, but some of the REPORTS
that are mandated in section 7 are much more obtuse. Example 7.7.7 is a
case in point
In this example, the client requests the server to return the VEVENT
components that have the ATTENDEE property with the value
"mailto:lisa at example.com" and for which the PARTSTAT parameter is set
Maybe I missed it, but I cannot find the "feature" in my Calandering
client (Lotus Notes) that requires this kind of query. If I understand
it correctly it asks for all the appointments in a Calendar where Lisa
still needs to respond. I know I am tempting fate here, cos I know it is
here for a reason, but which Calendaring system currently does this and
why? and do all calendaring systems need to do this for interoperability?
I just wonder if it is worth prioritizing the REPORTs specified in
CalDav and making some optional. You stated above that the freebusy one
is not that useful, although I disagree with this. Are there others
that are not that useful but mandated. I saw folks on this thread
stating both that CalDav was already too complex and asking whether
REPORTs should be optional. Is it worth coming up with a more limited
> 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...
agreed, I'll see if I can garner any interest on this side.
> 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.
agreed, but it reduces the invention to a few functions vs. a whole new
> 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.
Yup, here is a good example of a freebusy listing in html
http://ifreebusy.com/neiljensen/freebusy. The XSLT to produce that from
an xCal representation would be a fairly trivial modification to the
existing web page.
> 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.
A GET with an XML or an iCal response can functionally match the
freebusy lookup REPORT in CalDav. It will be substantially less effort
to consume in a shipping product for reasons that I point out in gory
detail here http://robubu.com/?p=8, end of life'd jars, firewall issues,
custom parsers. These are all headaches that we don't have if we stick
to what everybody else is doing. I also failed to mention in that post
that it is also harder to automate tests for REPORT vs. GET. For a GET,
I can use cURL http://curl.haxx.se/docs/, httpunit
http://httpunit.sourceforge.net/ or even the browser. I don't know of
any WebDav equivalents that are as well maintained. Then there's load
testing, does anyone know if loadrunner
supports REPORT. All of this is more effort
> 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.
The GET proposal was to simply match the functionality provided by the
freebusy report in CalDav. I was assuming that use case analysis had
already been done to ensure that this meets the current needs. The GET
proposal is not to address any new functionality, it is just an
alternative approach to that currently specified, so I am confused why
any further use cases are needed.
More information about the Ietf-caldav