Subject: [calsify] draft-ietf-calext-subscription-upgrade-02

From: Дилян Палаузов <[email-masked]>
Date: Tue, 06 Oct 2020 07:53:13 +0300

Hello,

2 Introduction

>   Currently clients subscribe to calendar feeds as an iCalendar file
>   which is often published as a resource accessible using the
>   unofficial 'webcal' scheme.
can this be extended with:

… or by opening an iCalendar file, containing the SOURCE property.

Retionale: for a user to subscribe to a feed by clicking somewhere I
know by now two methods: when the user clicks a webcal URL, or when the
user opens iCalendar file (irrespective of the schema) that has SOURCE
property.  For the latter the software can do one-time import of the
data, or subscribe to the feed.  There is nowhere a description that
webcal: and SOURCE: are supposed to do the same.

8.  Link relations

  * subscribe-webdav-sync this is RFC 6578
  * subscribe-caldav - unless this is IP based authentication, what is
the difference between subscribe-caldav and subscribe-webdav-sync?  I
mean, unauthenticated server can be used for retrieving data from, but
not for uploading, or doing scheduling.
  
  Why is it distinguished between authenticated and unauthenticated
CalDAV (that use WebDAV sync), but not between authenticated and
unauthenticated subscribe-webdav-sycn?

Greetings
  Дилян

В 20:35 -0700 на 29.07.2020 (ср), [email-masked] написа:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Дилян Палаузов <[email-masked]>
Date: Tue, 06 Oct 2020 09:10:48 +0300

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