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

[Дилян Палаузов <[e-mail]>]

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
  Дилян