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

[Doug Royer <[e-mail]>]

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.


On 8/6/19 4:35 AM, Дилян Палаузов wrote:
> 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
>    Дилян
> 


-- 

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