GNOME Bugzilla – Bug 559345
Support CalDAV free/busy extension
Last modified: 2009-06-02 14:30:26 UTC
Please add support to Evolution for the CalDAV freebusy request described in the Draft Scheduling Extensions for CalDAV proposed RFC (currently at revision -05). While these extensions are still draft, the freebusy request is supported by many caldav clients and servers, and is very unlikely to change before finalisation of the RFC. The process to be followed would be: 1. At startup of the calendar: 1.1. Ascertain that the collection does support scheduling by checking for the 'calendar-schedule' value in the OPTIONS response. 1.2. Ascertain the schedule-inbox-URL for this user by making a PROPFIND request against the known CalDAV calendar along these lines: <propfind xmlns="DAV:"> <prop> <owner/> </prop> </propfind> The response to such a PROPFIND request will return the owner, which will be an appropriate URL to use for the next PROPFIND request to find the scheduling outbox collection. 1.3. Having the owner, a second PROPFIND request is now reasonable, to fetch the URL of the scheduling outbox collection. This PROPFIND request will be against the url supplied earlier in response to 1.2, as follows: <propfind xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <prop> <C:schedule-outbox-URL/> </prop> </propfind> 1.4. The 'scheduling is supported', 'owner' & 'schedule-outbox-URL' values should then be internally associated with the calendar properties. 2. When scheduling a meeting. 2.1. If the user has a CalDAV calendar for which 'scheduling is supported' is true, AND which has a non-empty 'schedule-outbox-URL', make a POST to the 'schedule-outbox-URL' with a content-type of text/calendar as follows: BEGIN:VCALENDAR PRODID:-//Ximian//NONSGML Evolution Calendar//EN VERSION:2.0 METHOD:REQUEST BEGIN:VFREEBUSY DTSTAMP:YYYYMMDDTHHMMSSZ ORGANIZER:mailto:user1@example.net DTSTART:YYYYMMDDTHHMMSSZ DTEND:YYYYMMDDTHHMMSSZ UID:someuidstringthatwillidentifythemeeting ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL: mailto:user2@example.net ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL: mailto:user3@example.net END:VFREEBUSY END:VCALENDAR The DTSTART and DTEND identify the start and end of the range of time being queried for freebusy information. The UID should be unique, and may be the UID used to identify the meeting which is ultimately scheduled. The ATTENDEE properties should indicate the addresses of the hoped for meeting attendees. 2.2. The response to the CalDAV freebusy enquiry will be in something like the following form (taken from a DAViCal CalDAV Server response): <?xml version="1.0" encoding="utf-8" ?> <schedule-response xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <C:response> <C:recipient> <href>mailto:user2@example.net</href> </C:recipient> <C:request-status>2.0;Success</C:request-status> <C:calendar-data>BEGIN:VCALENDAR PRODID:-//davical.org//NONSGML AWL Calendar//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REPLY BEGIN:VFREEBUSY DTSTAMP:yyyymmddThhmmssZ DTSTART:20081021T110000Z DTEND:20081106T110000Z UID:1e680b0e-ee15-4d63-844f-3e48aa92791f ORGANIZER:mailto:user1@example.net ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:ma ilto:user2@example.net FREEBUSY;FBTYPE=BUSY:20081021T184500/20081021T193000 FREEBUSY;FBTYPE=BUSY:20081023T184500/20081023T193000 FREEBUSY;FBTYPE=BUSY:20081028T184500/20081028T193000 END:VFREEBUSY END:VCALENDAR </C:calendar-data> </C:response> <C:response> <C:recipient> <href>mailto:user3@example.net</href> </C:recipient> <C:request-status>2.0;Success</C:request-status> <C:calendar-data>BEGIN:VCALENDAR PRODID:-//davical.org//NONSGML AWL Calendar//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REPLY BEGIN:VFREEBUSY DTSTAMP:yyyymmddThhmmssZ DTSTART:20081021T110000Z DTEND:20081106T110000Z UID:1e680b0e-ee15-4d63-844f-3e48aa92791f ORGANIZER:mailto:user1@example.net ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:ma ilto:user3@example.net FREEBUSY;FBTYPE=BUSY:20081021T220000/20081021T223000 FREEBUSY;FBTYPE=BUSY:20081022T220000/20081022T223000 FREEBUSY;FBTYPE=BUSY:20081023T220000/20081023T223000 END:VFREEBUSY END:VCALENDAR </C:calendar-data> </C:response> </schedule-response> Full detail of this proposed extension to CalDAV is available in the proposed RFC draft, which can be accessed here: http://tools.ietf.org/rfcmarkup?doc=draft-desruisseaux-caldav-sched In particular this request is covered under section 3.1.1 and 8.1.5 Thanks, Andrew McMillan.
Maybe I'm missing something here, but the above process seems to me quite complicate. I guess it's possible to workaround this even on servers without free/busy extension, when asking for events in the particular time range and modifying these values to free/busy components, right?
Yes, the process which is needed to get free/busy using the draft scheduling extensions for CalDAV is more complicated than just requesting a free/busy report. It does provide free/busy information though, and meeting scheduling, which is not available in other ways. Servers implementing the scheduling extensions may often allow enquiries following this procedure where the full calendar of the individual concerned is not public to the person requesting the free/busy. While it would all be simpler if everyone just used the CalDAV free-busy-query REPORT, that only applies to a *calendar* rather than to a DAV 'principal' whereas this enquiry applies to a 'principal'. As I understand it that is the main issue, and the reason why most clients (seem to be) ignoring the free-busy-query and jumping straight to some approach similar to the one proposed in this bug. If you have rights to request events, you can fake up a free/busy response, but it is likely to be a common admin decision to default that (a) all 'principals' allow others to enquire their free/busy information, but (b) all 'principals' deny others to see their event information. And then leave the users to relax the policy further for specific cases where calendars need to be visible to assistants or team members. In such a situation you would not be able to fake free/busy because you would not have access to the event information for the other principals. Regards, Andrew McMillan.
Reading my above comment I realized I really misunderstood the process. This is what I expected to be, but I thought before that I'm supposed to also send some additional data when creating meetings to the server about such meeting, which didn't make much sense and scared me a bit. Anyway, after more careful reading the process is quite simple, thus I implemented it here: Created commit a525fee in eds master (2.27.3+). Andrew, by the way, my change works fine for google, but not for DAViCal 0.9.6.3. I pinged you on IRC, but rather writing also here: there's a little typo, you return free/busy's 'schedule-response' in DAV: namespace, where it is supposed to be in urn:ietf:params:xml:ns:caldav namespace. Also, mails are compared case sensitively, which is not the best thing. I produced a patch for that, it's in sf.net in a bug about mail comparison (I do not know how to attach files to sf.net, I didn't find it in the interface there. But I can attach here, if you want. Just let me know.)