CalDAV Scheduling - functionality to Accept or Decline invites

[Peter Koch]

Hi all,

There's a short description of sabre/dav Scheduling functionality at
http://sabre.io/dav/scheduling/

I'm interested in the functionality to accept or declie invites but so far
I don't understand, what the scheduling functionality is doing (besides
creating rows in the schedulingobjects-table)

Kind regards

Peter

[Evert Pot]

Hi Peter,

Scheduling is defined in this RFC:

https://tools.ietf.org/html/rfc6638

It relies greatly on this specification as well:

https://tools.ietf.org/html/rfc5546

While we don't support everything described in those 211 pages, we support a large portion of it. I'd suggest to skim it a bit to get an idea of what scheduling is, and if you have more specific questions let me know!

Evert

[Peter Koch]

Hi Evert,

Thanks for your answer (and this wonderful software).

Scheduling is defined in this RFC:
https://tools.ietf.org/html/rfc6638
It relies greatly on this specification as well:
https://tools.ietf.org/html/rfc5546

While we don't support everything described in those 211 pages, we support a large portion of it. I'd suggest to skim it a bit to get an idea of what scheduling is, and if you have more specific questions let me know!

I have red those RFCs but I still don't understand the complete picture. Here's what I have understand so far:

RFC5546 describes iTIP-message and how they can be used by calendar users to inform other calendar users. iTIP-messages seem to be ICS-files that fulfill additional restrictions and these messages are exchanged mostly between organizers and attendees.

Without Caldav auto-scheduling iTIP-messages are exchanges via email so your calendar-application must be able to send emails and your email-application must be able to store data from ics-attachments into to your calendar system.

RFC6638 seems to specify how iTIP-messages can be exchanges directly between two calendar-users if they are using the same CalDAV-server. In particular iTIP-messages from a sending calendar user will be stored directly into the inbox of the receiving calendar user.

If that was true, auto-scheduling would require a calendar-application which has the additional functionality to display the contents an inbox and let the user decide wether to accept or decline the invitation. Is that correct? And if yes - which calendar-application has such functionality?

Does auto-scheduling makes sense if the calendar-application is Thunderbird/Lightning or Outlook/CalDavSynchronizer?

Kind regards

Peter

[Evert Pot]

Hi Peter,

The benefit of auto-scheduling, is that clients don't need to understand it in order to benefit from it. If a client does a PUT request to create a new event, and that event has an ORGANIZER that matches the current user, and an ATTENDEE that is on the system, sabre/dav will automatically create an item in the inbox for the recipient and a new calendar object on the calendar of the recipient.

Likewise, when that user accepts the invitation by setting PARTSTAT=ACCEPTED, the original organizer's calendar object will also automatically get updated with that information (as well as every other attendee).
 

Does auto-scheduling makes sense if the calendar-application is Thunderbird/Lightning or Outlook/CalDavSynchronizer?

So, yes, it does. The inbox is actually not very interesting and is ignored more and more by various calendar client. Most of the information that's in the inbox can actually be inferred from calendar objects that are already on the calendar.

Hope that explains it.

Evert
 

Kind regards

Peter

[Peter Koch]

Hi Evert

2017-02-15 2:03 GMT+01:00 Evert Pot <ever...@gmail.com>:

Hope that explains it.

Yes - it did.

The benefit of auto-scheduling, is that clients don't need to understand it
in order to benefit from it. If a client does a PUT request to create a new
event, and that event has an ORGANIZER that matches the current user, and
an ATTENDEE that is on the system, sabre/dav will automatically create an
item in the inbox for the recipient and a new calendar object on the
calendar of the recipient.

Likewise, when that user accepts the invitation by setting
PARTSTAT=ACCEPTED, the original organizer's calendar object will also
automatically get updated with that information (as well as every other
attendee).

That makes sense to me. So the auto-scheduling mechanism does not accept or
reject invitation but it just places invitations into the attendees
calendars with status NEEDS-ACTION. And if the attendee accepts/rejects the
invitation the calendar entries of all other participant will be changed
immediately..

In our case there's one big advantage. If user A invites user B the
(tentative) invitation will be immediately visible to all users. But user B
won't be notified by email about the invitation. Can we configure
auto-scheduling such that calendar-entries will be automatically created
and email-notifications will be sent as well?

So, yes, it does. The inbox is actually not very interesting and is ignored
more and more by various calendar client. Most of the information that's in
the inbox can actually be inferred from calendar objects that are already
on the calendar.

Can I just truncate the schedulingobjects-table once in a while to prevent
it from getting bigger and bigger?

Thanks very much

Peter