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

[Robert Yates]

Cyrus,

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.

Rob

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

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

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
   to "NEEDS-ACTION".


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 
mandatory set?

>
> 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 
query syntax.

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

agreed

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

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

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 
http://www.mercury.com/us/products/performance-center/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.