Evolution - copying Caldav events - CALDAV:no-uid-conflict

[dilyanpalauzov]

When I try to move an existing event within the same user on cyrus with Gnome Evolution 3.28.1 the latter first does the equivalent of

curl -u X:Y -XPROPFIND  -H"Content-Type:text/html" --data "
<propfind xmlns='DAV:' xmlns:CS='http://calendarserver.org/ns/'>
  <prop><CS:getctag/></prop>
</propfind>" https://server/dav/calendars/user/X/Default/

for the new calender, and then the equivalent of:

curl -u X:Y -XPUT -H"Content-Type: text/calendar" --data "
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20170528T094321Z
UID:4201f067-5833-4362-a1e3-8350b7fee039
DTSTART;VALUE=DATE:20180528
SUMMARY:A BC
STATUS:CONFIRMED
TRANSP:TRANSPARENT
RECURRENCE-ID;VALUE=DATE:20180528
DTEND;VALUE=DATE:20180529
RRULE:FREQ=YEARLY
CLASS:PUBLIC
SEQUENCE:1
CREATED:20180506T183417Z
LAST-MODIFIED:20180506T183417Z
END:VEVENT
" https://server/dav/calendars/user/X/Default/4201f067-5833-4362-a1e3-8350b7fee039.ics

on which Cyrus 3.0 answers with:

HTTP/1.1 403 Forbidden
Content-Type: application/xml; charset=utf-8
Accept-Patch: text/calendar; charset=utf-8; component=VPATCH; optinfo="PATCH-VERSION:1"

<?xml version="1.0" encoding="utf-8"?>
<D:error xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <C:no-uid-conflict><D:href>
    /dav/calendars/user/X/f7e23514-7daa-4b3f-8706-2cd597da7faf/4201f067-5833-4362-a1e3-8350b7fee039.ics
  </D:href></C:no-uid-conflict>
</D:error>

Here 4201f067-5833-4362-a1e3-8350b7fee039 is the UID of the old event in the old calendar and PUT contains it.

RFC 4791 says:

 (CALDAV:no-uid-conflict): The resource submitted in the PUT
      request, or targeted by a COPY or MOVE request, MUST NOT specify
      an iCalendar UID property value already in use in the targeted
      calendar collection or overwrite an existing calendar object
      resource with one that has a different UID property value.
      Servers SHOULD report the URL of the resource that is already
      making use of the same UID property value in the DAV:href element;

                <!ELEMENT no-uid-conflict (DAV:href)>

According to my understanding, I admit some time passed since I read the specifications, the old calendar for the current user and the new calendar for the same user are different collections and the new collection has not yet allocated the UID, so the UID is not in use and this error shall not be returned.

[brong]

A copy doesn't generate a new UID. Strictly, this could be allowed to be legal if we did two things detected whether it's a "scheduling resource" and either:

1. didn't allow COPY for scheduling resources; or
2. allowed copy, but always updated all copies if the user updates one.

Hrm, yeah - the restriction on scheduling resources is this:

3.2.4.1. CALDAV:unique-scheduling-object-resource Precondition

Name: unique-scheduling-object-resource

Namespace: urn:ietf:params:xml:ns:caldav

Apply to: PUT, COPY, and MOVE

Use with: 403 Forbidden

Purpose: (precondition) -- Servers MAY reject requests to create a
scheduling object resource with an iCalendar "UID" property value
already in use by another scheduling object resource owned by the
same user in other calendar collections. Servers SHOULD report
the URL of the scheduling object resource that is already making
use of the same "UID" property value in the DAV:href element.

Definition:

 <!ELEMENT unique-scheduling-object-resource (DAV:href?)>

Example:

 <C:unique-scheduling-object-resource xmlns:D="DAV:"
     xmlns:C="urn:ietf:params:xml:ns:caldav">
   <D:href>/home/bernard/calendars/personal/abc123.ics</D:href>
 </C:unique-scheduling-object-resource>

But in general - our main issue here is how to handle them via JMAP, because the UID is used as the identifier, and if multiple copies can exist that's fine, but they should all update to the same content if one is edited, because otherwise finding the "correct" version is really hard. It's easier with IMAP because message content can't be changed!

[dilyanpalauzov]

In this particular case it is not COPY, but PUT.

How can MOVE trigger CALDAV:unique-scheduling-object-resource, if the server does not create new object in this case, considering all calendars of the user, and the precondition makes sense when new objects are created?

[ksmurchison]

First, as Bron stated, allowing more than one resource to have the same UID for a given user makes handling scheduling more difficult (although not impossible). I believe that the Apple CalendarServer also refuses to allow multiple resources to contain the same UID.

Second, what is the actual use case to have the same resource in multiple calendars owned by the same user?

Third, if I were to allow multiple non-scheduling resources to have the same UID, I would treat them as distinct resources, and not bother to keep them in sync with each other . This would be the simplest implementation from the server side. I'd leave it up to the user/client to keep them in sync if it wanted to.

[dilyanpalauzov]

When a user with several calendars (on the same server) configures them in Gnome Evolution, the calendars handled are absolutely distinct from each other. So changing the underlaying calendar for an event is implemented first by a PUT on the new calendar, and if there are no problems, probably with a consequent DELETE on the old calendar.

If the server rejected such a PUT with CALDAV:unique-scheduling-object-resource, which sounds feasible in this case, according to the specification it can also reject under certain circumstances a MOVE with CALDAV:unique-scheduling-object-resource, so MOVE is not panacea. When would MOVE fail with CALDAV:unique-scheduling-object-resource?

[brong]

MOVE will only fail with CALDAV:unique-scheduling-object-resource if you're moving between users and the destination user already has a copy of this event. It won't fail that way on a move within a single user.

You really can't just go DELETEing and PUTing scheduling events, because the server is going to automatically send CANCEL and REPLY emails to the organizer or attendee depending on your role within the event. CalDAV has a lot of implicit server behaviour.

[dilyanpalauzov]

So in this case httpd shall return
CALDAV:unique-scheduling-object-resource instead of CALDAV:no-uid-conflict.

[ksmurchison]

Yes, it should.