search

Kozea / Radicale

A simple CalDAV (calendar) and CardDAV (contact) server.
https://radicale.org
GNU General Public License v3.0
3.22k stars 424 forks source link

who changes LAST-MODIFIED property #85

Open sla29970 opened 10 years ago

sla29970 commented 10 years ago

Apple iCal on Mavericks does not change LAST-MODIFIED when editing a VEVENT. Gnome Evolution does change LAST-MODIFIED when editing a VEVENT. It looks like Evolution does not see edits unless LAST-MODIFIED changes, and it looks like Apple believes that it is the server responsibility to produce self-consistent values of LAST-MODIFIED. RFC 5545 seems not to specify who is responsible for the value in LAST-MODIFIED. Should radicale ignore any value from the client and always update LAST-MODIFIED using its own notion of the time?

liZe commented 10 years ago

First of all, thank you for this report, that's an interesting point I didn't met before.

RFC 5545 does not tell anything about who is responsible because this RFC is about the file format (iCalendar) and not the protocol (CalDAV). Of course, when the file is on the filesystem, the software creating the content is obviously responsible for the LAST-MODIFIED field.

The problem is: with CalDAV, which software is responsible, the server or the client?

My point of view is that the client is responsible. CalDAV is a protocol designed to provide a powerful read/write access to iCalendar files, just as filesystems are "protocols" designed to provide a powerful read/write access to files. When Apple iCal accesses files stored on the filesystem, it must modify the LAST-MODIFIED fields, or at least totally ignore them if it does not want to handle them. It should be the same through CalDAV.

The server is responsible for parts such as etags, just as a filesystem driver is responsible for last modification times on files, because these are metadata. The LAST-MODIFIED field is a data, and clients are responsible for data.

Of course, that's just my point of view, and as I'm a bit lazy, I may not be neutral :wink:. The real question is: is there a bug caused by this behaviour? If there is, I may be interested in finding a solution. If there's not, then I think that this bug should be reported to Apple :tongue:.

sla29970 commented 10 years ago

I have set my system clocks wrong, then created and edited events at google calendar using both iCal and Evolution. It is clear that google calendar ignores anything that either client sets in LAST-MODIFIED. It makes sense that if the meaning of LAST-MODIFIED is to be self consistent across a wide variety of clients on platforms of dubious clocks then the setting of LAST-MODIFIED must be done by the server, not the client. Is there any impediment that keeps radicale from following this advice?

sla29970 commented 10 years ago

I note that google calendar also sets CREATED using the server, not the client. This in combination with RFC5545 also may place constraints on who sets the value of DTSTAMP, but I have not explored all those client/server interactions. Nevertheless, in the RFC the values of LAST-MODIFIED, CREATED, and DTSTAMP all are defined using the phrase "in the calendar store", and I think that is an indication that the authoritative time must belong to the server, not the client.