From nobody Fri Aug 2 13:40:48 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CA71200E9; Fri, 2 Aug 2019 13:40:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <156477844694.20999.13543356248996606417@ietfa.amsl.com> Date: Fri, 02 Aug 2019 13:40:47 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-14.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:40:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Event Publishing Extensions to iCalendar Author : Michael Douglass Filename : draft-ietf-calext-eventpub-extensions-14.txt Pages : 33 Date : 2019-08-02 Abstract: This specification updates RFC5545 by introducing a number of new iCalendar properties and components which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar RFC5545 to allow for data that is directly pertinent to an event or task to be included with the calendar data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-14 https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 2 18:41:27 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ED612002F for ; Fri, 2 Aug 2019 18:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlM5-w7f7sKZ for ; Fri, 2 Aug 2019 18:41:24 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD18120024 for ; Fri, 2 Aug 2019 18:41:23 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id s22so56321446qkj.12 for ; Fri, 02 Aug 2019 18:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=QvYB79qg255NhfdC3O04tMXSGtSFgQDsw/bEGyVpkVc=; b=PPK887amMl7l1BvarghD3NTPMo/1fberOnmF0feifPviK3ZFhrvpY4kCaC/DEN4R9f ShQ54wevhTbxlf7cUCcdUmeAQO1KszeSBWAbOCG5boqc1cP9x5AC82LeLjDelxVhFyEo n4Lsl92/yF71UZiY/lH3zW9frce2Tk3v5sk4xuNliZZos7WHmP0iM0e6uNlAApIh0HRB nwjdvnV7qTQ9VB2I16S5Jc7X4hNRK7qqOglsmANM3HD6wZ3XXyAYC5g/CKSeEPSPr1pg lwYsZXOo47LIK/jdVwfib3/rhjE7W+SfoNlomv/XatRxtY/WLQnWo6lEncd3wvMdzE+j YEdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=QvYB79qg255NhfdC3O04tMXSGtSFgQDsw/bEGyVpkVc=; b=Zr1uCVvG2oEYx2zFBdge3S/GATdvuzcTxnoPt26TRkbZCtSS/KWichBBM539DamWUw iaXuaPIj3pjsvKckiYlcbRgY4dLJxC+oNc4f6lR9m0PMrbcnzZdguU0ICXBmyRdib/h7 z2wa+VzVu23vLBL9x5oBgajYpxCLCNhwsWABHPF56vb0nncDd+ZFAAFuVK0XNULMG+gQ JZ4Jhu3hMLJ2RAG6lLY0SkY5FR51/5SMH64nxz8KsU80u7Hq7lkn/H41esd5Sm6K14WJ OmVDsgQ7LqM6+ECijIDHN5m2zotSzH2swDCmFu+6MZC+ckdmuSkLwpFfhIbotMLa4jx6 Arjg== X-Gm-Message-State: APjAAAWJAVkgO27JJAN/Aboonxh2W8APNPbBiNRqPg7T9r60QU5PHITG 4wV1xY2r2L95fPvumj587fZyoQ8T X-Google-Smtp-Source: APXvYqyR5JOQeqUJ58c0oEtcAH2BCmJbt1YLwO+0VyymiDBSXgOBFYxLCrhdFgyaow0U8wNFwlFYxA== X-Received: by 2002:a05:620a:232:: with SMTP id u18mr7280362qkm.131.1564796483032; Fri, 02 Aug 2019 18:41:23 -0700 (PDT) Received: from b-192-168-133-50.dynapool.vpn.nyu.edu (vpnrasb-10wp-pat-01.natpool.nyu.edu. [216.165.95.86]) by smtp.googlemail.com with ESMTPSA id 18sm34646831qkh.77.2019.08.02.18.41.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Aug 2019 18:41:22 -0700 (PDT) To: Calsify , Daniel Migault From: Michael Douglass Message-ID: <7cd6abdc-edbc-6304-2bb4-5d71b8ee048f@gmail.com> Date: Fri, 2 Aug 2019 21:41:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] draft-ietf-calext-eventpub-extensions-14.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 01:41:26 -0000 I just submitted draft-ietf-calext-eventpub-extensions-14.txt Changes were to remove updates to SOURCE and use STRUCTURED-DATA instead. I also fixed one of the STRUCTURED-DATA examples. I will be cruising around Alaska for the next 10 days with little or no internet. From nobody Tue Aug 6 03:36:12 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AB812022E for ; Tue, 6 Aug 2019 03:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEyNYdyET6ST for ; Tue, 6 Aug 2019 03:36:08 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837DD120147 for ; Tue, 6 Aug 2019 03:36:08 -0700 (PDT) Authentication-Results: mail.aegee.org/x76AZwL1001608; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1565087763; i=dkim+MSA-tls@aegee.org; r=y; bh=s5yD26nMrCth1qeWDGfOsV6l4+69vVuI/4OAxby/Ghg=; h=Subject:From:To:Date; b=XOaL98IMC6TPGzDcFz8UlhSJFiMLP6ZbYfVypdwOb9e3PfsMONV1jyZlELW/L7Qe6 bWLgQJSyIZPe8lxyskHE+YW/sV2jTD3OCF5qThx5FOlYURonABByLh5k6xSCa0DKTl IKNmQfl+lnrz9WLM7yyvMdq/3mcBoBAm4Z5UVKe2KPYZHzHj+4oyBtyEs/6bsD/dY2 9ddeQHC9nQpMcsAXfZ5WyTJO3TGQ+7gu1xoCzwmMMUGnWegUAMzU8UpOKhrpP+0JWe 3m/QYR2Fbe5qkpjEizNSE/GdEvouqDWuzYWUNoA2jjw71ZLLTyQNLOhFMBQ505F5Ip yQ1d/o7bX0U+YwbcwPfujkIFIxML1zpTcxLs2gMAcQuw1vV+/W1V0wPDF725UdVnov +ieTiundxp4sS5wW7xQMhxzvWPxib1Bw8mGJo3E77Oi+UeCPzWUULPJbcYomBqachg R41rWdl1nM6CNBHvNAie5qdND0n8hz4o7qIWXoqmC1QIxLRL21++MB6rOmnXDW4rDp 90UWKgtWFsPTg/S4/BIlWldih9jMHMK43m107SYuRptzc+4Xx9M0OOkT6TjxD2N03j 8z/arcksXAnyB87wx7sUCbZKwG01zsEeiT9zbPMT48SjbkoJEcdK0fNrxMadZcmi2P g96q+lT9LoIbK5JdBnA8PpZA= Authentication-Results: mail.aegee.org/x76AZwL1001608; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x76AZwL1001608 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 6 Aug 2019 10:35:58 GMT Message-ID: <521fb368aebb4294888468efaf1dceace864fa97.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: calsify@ietf.org Date: Tue, 06 Aug 2019 10:35:58 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [calsify] The two ways of cancelling an event by an organizer X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 10:36:11 -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 nobody Tue Aug 6 14:29:13 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60ED120033 for ; Tue, 6 Aug 2019 14:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOSkiGCkzHF5 for ; Tue, 6 Aug 2019 14:29:10 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F28E120025 for ; Tue, 6 Aug 2019 14:29:10 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id a127so68744835oii.2 for ; Tue, 06 Aug 2019 14:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=r9BhCPdQyY2pQd8xgsUdUzPdCfdtysLUpo0R3tO4sB4=; b=OzR8kKFB/DQq+gxXm9Qppb3PpfnRbdWym+Eunt8eNVZTupb97eNueeyfxFLG8QIukp 6mgZ45N5KpTwtSIXq+l9gaDvSdb/drbxRyAxCc6y0S8bT6BS0kDPgrW00iFb+yYM536Z l6uF4h/nuXLXMv31mY85hK4M9nqoOyqgQ214KfCqasOR+5CETdpyRMPVqisD0jl/4BiJ H20E30xpfweekT0Xk/q30dheETyBBjLiG/3ZXorK8DEdo20qmgJ6LJMNihc3WO7pwo7A n7NfsxGGRTrRctzRvZJzmd8sfjyfWWXmHjWrzz4jEmPt/TGN0QeAfphfdF6pSf9WZMNa WgrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=r9BhCPdQyY2pQd8xgsUdUzPdCfdtysLUpo0R3tO4sB4=; b=DW1f65IALvahRz8+o2GiF0TB/KjFusxNJGYNXhKYoYPzCyGJu6SVb60pYrXV1qJnVw 9xpOYCYwRZJcCzWY9UbMhJdPjsA0p208yRIqUDns6V6/O/V9LA6k13Q9Ktml1GRMfxqr M1cR3zpknfesdTqapmND90DuDSqCULp3RBnmTTzGmcOfD0D1L4bKIwtRdglhtwBTaxx4 0nRtg90iFMVPigtoXv7JivJpXZE2HeYHYmkapqn6bAgmn2/8uN0Oub/DqdCl+LysBDTP do77jQSlp0+fMUzC35/AsNbVQHcm28zcgRwGEkVksQ3C3oyVH3TOuWKWBegBx3MZP+kr 6JzA== X-Gm-Message-State: APjAAAWzRB+cGYDaPzBTlr0Gk1bDzeQbo8J9+lxQ7kltEWTQpBxGivTL B2PJLg27XG4TT9pEh4JfWiNaAoLTI3si X-Google-Smtp-Source: APXvYqxB1xOrCCayHsOX5zYBhoTC+7/m+FJbqU2X6uNIVQU+kYM9YD2BWml9surUdtDNKiO+8wBOIQ== X-Received: by 2002:a02:aa8f:: with SMTP id u15mr6512238jai.39.1565126948938; Tue, 06 Aug 2019 14:29:08 -0700 (PDT) Received: from [192.168.1.7] ([174.27.19.182]) by smtp.googlemail.com with ESMTPSA id t14sm70603178ioi.60.2019.08.06.14.29.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 14:29:08 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <521fb368aebb4294888468efaf1dceace864fa97.camel@aegee.org> Organization: http://SoftwareAndServices.NET Message-ID: Date: Tue, 6 Aug 2019 15:29:07 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <521fb368aebb4294888468efaf1dceace864fa97.camel@aegee.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] The two ways of cancelling an event by an organizer X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 21:29:12 -0000 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) Douglas.Royer@gmail.com 714-989-6135 From nobody Wed Aug 7 02:03:35 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71898120315 for ; Wed, 7 Aug 2019 02:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS7LjbE_clBT for ; Wed, 7 Aug 2019 02:03:32 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3FE120303 for ; Wed, 7 Aug 2019 02:03:31 -0700 (PDT) Authentication-Results: mail.aegee.org/x7793RDU009917; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1565168608; i=dkim+MSA-tls@aegee.org; r=y; bh=d8kd01sdsrPLZW4h0j1MFHyFdC0OMjoXFn7GsPcODjA=; h=Subject:From:To:Date:In-Reply-To:References; b=BL4Dz9XuDsxBdIQVeRtOjkENahr/6L7vyRXj5oLD0yoKeH/6DKfL/N285fUwatTkc Ri2+1RsgUNs+oxqW5fRvp6gdDIZN0jYpq3Ct3zASHzaXxxK4FZZCSrDuspLjtS9Wuw MseidFmXIyX2xSrsFcRxrccEqbJohC3/M2pyM9qp4MkMCAyb/3zZLNFcgTbu6uc+W+ 6ZUSUETjPEQJN7EJcwOKPipxGI4k+Ih4IdvEcF62SfxZFkWEwQAqv4werL/260a3hn 1MehxRHK8w0hVjZdNHcKh3PVIbJASDSJ7Xuw1LeUe1AC/+acOFUZFxa56WkegYccA7 2CFiFW0iYwAzJdWmpwSp80x/WDaIUQ3JBWpo4g3LnKxHDm1JVQ/ajVqS3pqTij8B1w O8em5I0+hhuajzlzE7bSIDaExwYuO7R0i3Aypg9t0NORyWv0HdrxEpcc1EhZA71t+5 SkpzZHtQ0o45pBbap/yLQVkl2z9IOOfyCLX44I/YGK6DtpKk7hGrjxp1U9cKguVwO6 I2DM2NGRErxTZOlxJa0lX8x+azvhR2jh0MkrRTY+8gv3roCDUIDgltDgF3pBnFXlQr Da90bgtMzdRyn5GWbEEIg9VQbjK/KTm5pIrrsxdg9mVjo9Jr5QRBCSe+q6InoYRC4y 85iBRJWqYhYIUrdRIpsVZd9A= Authentication-Results: mail.aegee.org/x7793RDU009917; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x7793RDU009917 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 09:03:28 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Doug Royer , calsify@ietf.org Date: Wed, 07 Aug 2019 09:03:27 +0000 In-Reply-To: References: <521fb368aebb4294888468efaf1dceace864fa97.camel@aegee.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [calsify] The two ways of cancelling an event by an organizer X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 09:03:34 -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 Дилян 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 > > Дилян > > > > From nobody Wed Aug 7 15:01:39 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A751206A2 for ; Wed, 7 Aug 2019 15:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYrV6zyJ8Tpq for ; Wed, 7 Aug 2019 15:01:17 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5881E120232 for ; Wed, 7 Aug 2019 15:01:17 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id n5so110586228otk.1 for ; Wed, 07 Aug 2019 15:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=b6CcOlJbqdKMtwdX3tZSDqTxlvp64EyTS3VHRiwKnxo=; b=VFszYUDPWFYXzi0iu7xI2kB2HBJNRotebq13I+qMiheyddV+Q2vwAOVqe7SCMLYTKF mBa8Ghc/g3x+rLq3lqUBrawPZ5wRn259YZU2xlMepYpfKTBvFYEnRjNnabVzbyp8IVKI JKWfYIBKrniIkYUxh8sQE8Ez+5aedBABNidj2nPS9L/cI/H9v2SBSweLJf2+rqVtFkW9 A8/6UlDyNy9UMirjpubOONUqtdInl+QdhnvRZK++ucVojVLNKk2iGEE4EzJ5F1M8to/X Um7cyOSYrqWQhmf61zdLGPsJ4fgP+1dc9Z2wEpgUdODLbJ8x2VYpC3r2khrmZ/4KHB50 fmAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=b6CcOlJbqdKMtwdX3tZSDqTxlvp64EyTS3VHRiwKnxo=; b=Lo1WxHCBiw4wtBlIaPXqbl+lYx7oNGJJg/YFKVD8+lkk+mmUqigSOwzacG45sO2BG3 COJxGF9dTn/CubINM8JO6S6Qa0I+oB12Xw54VO0Bt1dNy8p9D0NienrVvVmreGR2nMJG QnPwk/pmEJEaMitZgFymBYA4cEzyU7sMKOuDVCYNf+J6nLC2UXoOPkDcwntV2X5Y9tnx H4SSt7rt3hjnnMj93khOc21TATnzRd5IpDNXgyveie3r6u9shQey+dnXVPjqgRkih6BH G7k7CCOnksujO709dGqlcZvGRjWvuQcaQb4W6E87Ue0hBXlgNCaUhdUjprjDmQyMXKsr xB/A== X-Gm-Message-State: APjAAAUr9LLhZb6HtW6E2ky0FedaFiotI8auKmr/Zb1HyqdfnprCwwOl 0d0soMo5gTW+m/05d8B0JLdsI26/MR8o X-Google-Smtp-Source: APXvYqx+4oBZ8zZZuIawjCkiLcJmytm/NgR7Mb/e713IDuMBtlpzKK3KVCDKLM8trMREerpXmpR6DQ== X-Received: by 2002:a5e:9408:: with SMTP id q8mr6627747ioj.223.1565215276355; Wed, 07 Aug 2019 15:01:16 -0700 (PDT) Received: from [192.168.1.7] ([174.27.19.182]) by smtp.googlemail.com with ESMTPSA id w14sm3066463iob.58.2019.08.07.15.01.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Aug 2019 15:01:15 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <521fb368aebb4294888468efaf1dceace864fa97.camel@aegee.org> Organization: http://SoftwareAndServices.NET Message-ID: <21eb1982-76f1-913f-3d3b-4cb46c01e346@gmail.com> Date: Wed, 7 Aug 2019 16:01:14 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] The two ways of cancelling an event by an organizer X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 22:01:25 -0000 On 8/7/19 3:03 AM, Дилян Палаузов wrote: > 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 > Дилян 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? -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Thu Aug 8 08:39:54 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FCD12006D for ; Thu, 8 Aug 2019 08:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYZsLrxN4MT5 for ; Thu, 8 Aug 2019 08:39:51 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51009120041 for ; Thu, 8 Aug 2019 08:39:50 -0700 (PDT) Authentication-Results: mail.aegee.org/x78FdkYL031969; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1565278787; i=dkim+MSA-tls@aegee.org; r=y; bh=XrtLfmyfLTo8qicZ8f4g4iotohbVXEhA8yBb4amEQ0A=; h=Subject:From:To:Date:In-Reply-To:References; b=bHPsRrU0nsE0l2hOJEvOKa9mbdU43QsfoTeh1X1CKg/I+c0q1lb+uhDArk4oV/q7L dBBTiF1021buR/psZj3E5JMsrzSunsqFPYezuLC0KoQ2v4jGbLlIBaEcSuM/8WYdTo ElRZiRWDo4k4J3iWRk+Kr46HFwxnUDbz6/55YTZ58badSgZh4YxdnGWVNSgePuSaUO PBAkXnC6GOINMNXDhvQQWcLFV/w3iAaogJBfZazomb21nGM4/Y3iEcRC6J2PmHeLVH u6vQipsesEYcY0VMsbEfuzWbcByXS71y4eIKQs1fQjVhqmAA2afKYxHvIFNt0kRBer aL/yifhq3bjfmLQmtgHbKXd5aKV6zGI59GQ/dB0NG96lqWOm4yJBLT1/cimWIeiEYf JstfpRd64RQcPKNcvvBFbyS8HR43VRvoVWKYtyttU5/O0b+FsnJZgMd+RuMZDJ/ZWd nRPgpadg3iFgIgoDvFapM9D3Qxk5dlMJ5sZWHN9wZ9W7LKu5sX9srOASRgRG+ATFgb IU2tGJPWLplXT7OZC1vEiw2DiSoAj5N6HNQvroQ+r5w3j5NdO9vlXWYgdqBwsMPJF8 Xn3ZP+GXqGA6DI0i2feoOBdbOApIKmVeXkpi7qVh9zzXZR5nPhFfM8kPa9YbVh4LKj 9rCZ7skM5jlLJ92LHYHpYLKc= Authentication-Results: mail.aegee.org/x78FdkYL031969; dkim=none Received: from Tylan (95-42-103-179.ip.btc-net.bg [95.42.103.179]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x78FdkYL031969 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 8 Aug 2019 15:39:47 GMT Message-ID: <95b717f7e5ace86bbdd892c3e3099d83f6fe7ea2.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Doug Royer , calsify@ietf.org Date: Thu, 08 Aug 2019 15:39:46 +0000 In-Reply-To: <21eb1982-76f1-913f-3d3b-4cb46c01e346@gmail.com> References: <521fb368aebb4294888468efaf1dceace864fa97.camel@aegee.org> <21eb1982-76f1-913f-3d3b-4cb46c01e346@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.91 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [calsify] The two ways of cancelling an event by an organizer X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 15:39:54 -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 Дилян On Wed, 2019-08-07 at 16:01 -0600, Doug Royer wrote: > On 8/7/19 3:03 AM, Дилян Палаузов wrote: > > 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 > > Дилян > > 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? > >