[calsify] draft-ietf-calext-subscription-upgrade / STATUS: DELETED

Дилян Палаузов <dilyan.palauzov@aegee.org> Tue, 06 October 2020 06:11 UTC

Return-Path: <dilyan.palauzov@aegee.org>
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 1BA433A119F for <calsify@ietfa.amsl.com>; Mon, 5 Oct 2020 23:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 svFtez8T-bC4 for <calsify@ietfa.amsl.com>; Mon, 5 Oct 2020 23:11:54 -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 B837F3A11AA for <calsify@ietf.org>; Mon, 5 Oct 2020 23:11:52 -0700 (PDT)
Authentication-Results: mail.aegee.org/0966AtFD3408091; auth=pass (LOGIN) smtp.auth=didopalauzov@aegee.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1601964710; i=dkim+MSA-tls@aegee.org; bh=QpkwhW8AOZZkD8P2fFiGJP+urKFYmszjrKJfv/S9f0I=; h=Subject:From:To:Date:In-Reply-To:References; b=G00t2Y9CmF2ZJaGFQ/5aZssNHhV2rbXNU8wzYFwphg/FLPv2FnkAwSFtjufWgq2sO JDqbdU05AugS0KGVF9ja3V2qAprHslQa9JRMR2dqALVeT/mYRxdv16zSr87jVxUHFn dmCx8wBY8UPA5KH7qthBz0XEwCR1AkEiVXC0XDiLvZw0lLofFU6gK7Z2HL5Va56opy kOceEfK54TWNsJEwSI+vcr6IyYH744JpNEDiUR8FD26JBFqR95HtU/Mx0xonV+OvqC 9j00VzmsK80vKJ+3xgqpaTyJ4C49nK2WrYL8rS7Rvyc3sDOIiio1YXGsM7DvFn6P45 5Z0GImJgIykGeWfwsC4hGIRT/RJI+E/w4Ol1MvfTHI3wrl+DkkTECxHs8l1FJWQ+UG 1slI/8iwp3OZnp0/jtMCf9dykclsyHzS8ezPNBKLNLxIJFN3ETSpWaSdoSE7iOhMD2 Bzyu/A2IZZjQm7NL/HN12irEE5KCTXSPO44NZkEbRBVkp747+CorxzTewS4IRjGAnc e2TbVLyHz86+uq2VM1YK/OV+KRJxie7P0w7qxMgfYmXebgfDyCJLUFSj+X4eu4Z9yE uufzO8U1dyyJpKeS5MScppYO8lywH5JMiQ0cLpPlqD0zqOUXPbrkYwYYvPL0kbDygz HnrM3qockYu4o4lKVoSljkyM=
Authentication-Results: mail.aegee.org/0966AtFD3408091; dkim=none
Received: from d (87.118.146.153.topnet.bg [87.118.146.153] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id 0966AtFD3408091 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <calsify@ietf.org>; Tue, 6 Oct 2020 06:11:50 GMT
Message-ID: <0a66c3aed23b8b1e5b2d5f11d6d37bb814f7f15e.camel@aegee.org>
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
To: calsify@ietf.org
Date: Tue, 06 Oct 2020 09:10:48 +0300
In-Reply-To: <159608014306.19132.12080107760086956798@ietfa.amsl.com>
References: <159608014306.19132.12080107760086956798@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-1.fc32)
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/2yUlGI-fdVdHl4m1LMwy0Gu5ssM>
Subject: [calsify] draft-ietf-calext-subscription-upgrade / STATUS: DELETED
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2020 06:11:56 -0000

Hello,

it has been a while, since I have not posted here.

When an announced event will eventually not happen, the publisher of
the event information has two options: delete the event entirely from
the calendar, or keep it with STATUS:CANCELLED.  The difference between
the options is nuance and there is no ultimatively right way to map the
fact the event will not happen.  Moreover, how to map the fact of
event, which will not happen, to iCalendar, is a decision that has to
taken by the publisher of the calendar and the feed-subscribers are
bound to the decision, if it is HTTP DELETE.

The case that an event is moved to another time, can also be mapped in
two ways:
• keep the old event with STATUS:CANCELLED and description pointing to
the new time, creating a new iCalendar object for the new time
• keep the same iCalendar object but with new DTSTART/DTEND/DURATION,
making the old event disappear from its original place in the schedule.

In case of  a public calendars, if a person sees an event, and later
does not see the event any more in the calendar, that person can
question her memory.  Keeping the event in the calendar with
STATUS:CANCELLED will not lead in the subscribers to the feeling that
the calendar server randomly deleted data due to errors.

“5.1.  Redefined Status property” adds as a third options:
* set status to CANCELLED
• set status to DELETED
• remove the event from the calendar entirely.

The redefined STATUS property updates the iCalendar Core Object (RFC
5545) specification irrespective of the other sections in draft-ietf-
calext-subscription-upgrade, yet it does not update the iTIP (RFC 5546)
constraints to say with which METHOD STATUS:DELETED can be used.

draft-ietf-calext-subscription-upgrade lacks means to communicate over
Enhanced GET, that the event is still in the calendar but has
STATUS:DELETED.

I do not see a difference between STATUS:CANCELLED and
STATUS:DELETED.  Or rather, I do not see when the STATUS shall be set
to DELETED and when to CANCELLED on HTTP PUT (in CalDAV terms).

I propose removing sections “5.  Changes to the iCalendar
specifications / 5.1.  Redefined Status property” from draft-ietf-
calext-subscription-upgrade and communicating the fact, that an
announced event will not happen, using only STATUS:CANCEL.

It is like publishing something in the newspaper.  Once it is
published, it cannot be de-published, it can only be rectified.

This has the advantage, that it is not up to the publisher of a
calendar to decide, whether volatile events shall be HTTP DELETEd, or
get STATUS:CANCEL, but the decision is up to the subscriber of the feed
(show or hide cancelled events).

Greetings
  Дилян

В 20:35 -0700 на 29.07.2020 (ср), internet-drafts@ietf.org написа:
> 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           : Calendar subscription upgrades
>         Author          : Michael Douglass
> 	Filename        : draft-ietf-calext-subscription-upgrade-02.txt
> 	Pages           : 15
> 	Date            : 2020-07-29
> 
> Abstract:
>    This specification updates [RFC5545] to add the value DELETED to
> the
>    STATUS property.
> 
>    This specification also updates [RFC7240] to add the subscribe-
>    enhanced-get and limit preferences.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-calext-subscription-upgrade-02
> https://datatracker.ietf.org/doc/html/draft-ietf-calext-subscription-upgrade-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-subscription-upgrade-02
> 
> 
> 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/
> 
> 
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify