Open dilyanpalauzov opened 6 years ago
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!
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?
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.
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?
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.
So in this case httpd shall return CALDAV:unique-scheduling-object-resource instead of CALDAV:no-uid-conflict.
Yes, it should.
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
for the new calender, and then the equivalent of:
on which Cyrus 3.0 answers with:
Here 4201f067-5833-4362-a1e3-8350b7fee039 is the UID of the old event in the old calendar and PUT contains it.
RFC 4791 says:
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.