0

I am studying CalDAV protocol.

I have some question for time conflict or overlap for CalDAV.

Let me explain by instance for some scenario. I made an event PM1 ~ PM6 in calendar. And then I try to made another event PM2~7 in same calendar. It is time conflict or overlap.

How does CalDav server resolve this conflict? Does server make error when second event make?

I did search out RFC 6638. But I could not find solution. Please help my question.

Thanks for reading.

Won-Sik Kim
  • 411
  • 3
  • 6

2 Answers2

0

It is up to the CalDAV client to decide how to behave when overlap is involved. If the client decides to write an event that overlaps another the server will write the overlapping event.

When scheduling is involved (userA wants to invite userB to a meeting but would like to avoid picking a time slot that is already busy in userB's calendar) the CalDAV client can query the FREEBUSY status for a user (see RFC 4791). There's also availability which allows a CalDAV client to retrieve a user's availability (think business hours).

diciu
  • 29,133
  • 4
  • 51
  • 68
0

The functionality Kim is asking for a very common one for business calendaring systems (not have the same person booked twice etc).

I think in the CalDAV world there are two parts to this:

a) First the client is supposed to perform a freebusy query to check whether a user is available. And then show a conflict warning or whatever seems appropriate.

This is how many systems, including btw Exchange work. Siri also does this kind of conflict detection (“hey, you already have an event at the time, shall I still create the conflicting one, master?”)

b) But in a reasonable system you actually need to guarantee that the information isn’t outdated at PUT time. I.e. that no second client has scheduled the same attendee/resource.

I think in CalDAV you can accomplish that by testing the sync-token or the CTag using an If header on the PUT. I.e. let the PUT only succeed if the whole underlying collection didn’t change. And if it did (the PUT will fail with a conflict), redo the freebusy, then try again.

I don’t think that there is a reliable way to do this in CalDAV cross collections (calendars), that is, if the availability of a resource changed because it got booked in a different calendar, the targeted sync collection won’t usually change its sync tag and the PUT would run through. The bad thing about CalDAV (w/ scheduling) is that PUTs are not idempotent anymore. Otherwise you could do the PUT, recheck whether it still has no conflicts, and if so drop it after the fact.

hnh
  • 13,957
  • 6
  • 30
  • 40