Subject: [calsify] The two ways of cancelling an event by an organizer

From: Дилян Палаузов <[email-masked]>
Date: Tue, 06 Aug 2019 10:35:58 +0000

Hello,

when an organzer cancels an event, the organizer shall be able to change the description of the event, explainging why
the event was cancelled and then send METHOD=CANCEL iMIP message to the attendees.  The attendees shall get a single
iMIP message, containing both the updated description and METHOD=CANCEL.

How can the genaration of a single iMIP message be achieved in terms of HTTP Scheduling?

There are two ways to cancel an event by an orginizer: delete it from the calendar or set STATUS:CANCELLED.

With CalDAV Scheduling Extensions, Attendees, and iMIP message generation by the server, when the organizer cancels an
event, the attendees shall get a 

Content-Type: text/calendar; charset=utf-8; method=CANCEL; component=VEVENT

message.

Moreover, RFC 5546 “iTIP” says that for VEVENT the Content-Type can contain method=REQUEST only when the status of the
message is TENTATIVE or CONFIRMED.  When the STATUS of the message is CANCELLED the method must be CANCEL.

Changing the STATUS of an event to CANCELLED and PUTting the new event over HTTP is modifying the VEVENT.  Doing HTTP
DELETE is removing the event.  RFC 6638 (Scheduling Extensions to CalDAV) says in sections 3.2.1.2 and 3.2.1.3 that when
the iCalender object is modified, then the METHOD is REQUEST and when the iCalendar object is removed, the method is
CANCELLED.

That sayd, when the organizer HTTP DELETEs an event, the generated iMIP is wih method=CANCEL and STATUS: CANCELLED.

HTTP PUTting an event with STATUS:CANCELLED is valid operation.

What shall happen, when the organizer sets the event STATUS to CANCELLED?  Shall it generate method=CANCEL iMIP
messages, or generate no iMIP messages?

When an event is CANCELLED, I want to change the description of the message, stating why the event was cancelled and
sent a METHOD=CANCEL message to the attendees.  The attendees shall get a single message.

If I change the description and HTTP PUT the event, then for the server is feasible to distribute an iMIP update
messages to the attendees.  If I HTTP DELETE on the next step the event, attendees will get a second message.

So, what shall happen here?

A. WebDAV-Lock the iCalendar object, modify the icalendar desription, PUT the modified object, DELETE the object und
UNLOCK the object, so that the server can generate a single message.  (Not so efficient.  With DELETE there is likely
implicit UNLOCK).

B. Submit the content of the modified object with the DELETE verb.  The content is submitted, as if the verb was PUT,
but returning ETAG and Scheduling-Tag on DELETE does not make sense.

I cannot find examples in RFCs for DELETE with content/payload, but neither can I find text preventing the
content/payload.  In particular https://tools.ietf.org/html/rfc7231#section-4.3.5 (HTTP/1.1 definition) says for DELETE:

   A payload within a DELETE request message has no defined semantics;
   sending a payload body on a DELETE request might cause some existing
   implementations to reject the request.

Can this be clarified by erratum to RFC6638 “Scheduling Extensions to CalDAV”?

Regards
  Дилян

---

From: Doug Royer <[email-masked]>
Date: Tue, 6 Aug 2019 15:29:07 -0600

I have not done HTTP based calendar code, but this seems valid:

Could you just add a COMMENT to the METHOD CANCEL object when you iMIP the cancel?
In the COMMENT, explain why. No need to update the DESCRIPTION or SUMMARY.

3.8.1.4.  Comment

    Property Name:  COMMENT

    Purpose:  This property specifies non-processing information intended
       to provide a comment to the calendar user.

-- 

Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Дилян Палаузов <[email-masked]>
Date: Wed, 07 Aug 2019 09:03:27 +0000

Hello Doug,

to force the server to use METHOD=CANCEL, the CUA has to use the HTTP DELETE verb.  It is not possible to add anything
to the deleted object, as DELETE currently does not have payload.

To modify the iCalendar object, like changing the description or adding comment, one has to use the HTTP PUT verb.

When HTTP PUT is used, one iMIP message is generated and when HTTP DELETE is used, another iMIP message is generated.

Regards
  Дилян

---

From: Doug Royer <[email-masked]>
Date: Wed, 7 Aug 2019 16:01:14 -0600

> When HTTP PUT is used, one iMIP message is generated and when HTTP DELETE is used, another iMIP message is generated.

As your talking iMIP, can you send them an email that describes the reason, and includes attaches (multipart related) the CANCEL object or CANCEL object URL?

--

---

From: Дилян Палаузов <[email-masked]>
Date: Thu, 08 Aug 2019 15:39:46 +0000

Hello Doug,

it is more practical if the iCalendar resources are uploaded via HTTP to the server and then the server decides how to
deliver the transport independent information: to local users via HTTP CalDAV scheduling, for remote users by sendnig
iMIP.

In theory it is possible, that the CUA updates the iCalendar object for the local users on two subsequent HTTP
operations, and for the remote users sending itself the iMIP messages, playing with the SCHEDULE-AGENT property
parameter per ATTENDEE.  So for an event with local and remote attendees, the iCalendar objects is distributed partially
by the server and partially by the clients.  However this moves complexity from the server to the client, or rathar
expects that the same functionality is implemented in both server and client, and, depending on the locality of the
user, the transport independent message is sent either be client or by the server.  Moreover, the CUA has to figure out,
if a user is local or remote, and so on.

It would be simpler, if the the intension of the organizer is mapped to the HTTP protocol and the server sends in
transport independend ways what the organizer asked for.  The one approach is to define payload to DELETE.

The other would be to send METHOD=CANCEL messages, when the iCalelendar object has STATUS:CANCELLED.  So everytime the
organizer modifies a cancelled invitation, the attendees get a new cancellation message with increased SEQUENCE.  When
the organizer deletes a message with STATUS:CANCELLED, the attendees get, or not, one more cancellation message.  Or the
intention of the organizer is read from the STATUS parameter and not from METHOD.  So an iCalendar object with
STATUS:CANCELLED and METHOD=REQUEST is cancelled... I do not know what would be right.

Now I think that not only orginizer has two ways to cancel an event: set STATUS to CANCELLED or delete the event, but
also the attendees have two ways to act on receiving events cancellation: set STATUS to CANCELLED or delete the local
copy of the event.

Regrads
  Дилян