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

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

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

On Tue, 2019-08-06 at 15:29 -0600, Doug Royer wrote:
> 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
> >    Дилян
> > 
> 
>