Subject: [calsify] I-D Action: draft-ietf-calext-subscription-upgrade-00.txt

From: [email-masked]
Date: Fri, 07 Jun 2019 08:43:14 -0700

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-00.txt
	Pages           : 15
	Date            : 2019-06-07

Abstract:
   This specification introduces an approach to allow subscribers to
   calendar feeds to upgrade to a more performant protocol.

   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-00
https://datatracker.ietf.org/doc/html/draft-ietf-calext-subscription-upgrade-00

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: Дилян Палаузов <[email-masked]>
Date: Tue, 11 Jun 2019 19:50:55 +0000

Hello,

this document does not talk about where the CUAs get the calendar feeds from, or how the CUAs can know, to which feeds a
user is subscribed.

One possible approach is to get the feeds from diverse web pages and keep then only on the client, while some servers
support the approach described at http://sabre.io/dav/clients/ical/#subscriptions .

My big question is:

A user gets a webcal URL, let’s say secured webcals://A/B .  Why doesn’t the client just do:

OPTIONS /B HTTP/1.1
Host: A

If the answer contains DAV: calendar-access, then apply the mechanisms from Calendaring Extensions to WebDAV (CalDAV)
RFC4791 and Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) to get all data; get the
changes since the last synchronization; get only events after certain date…?

Otherwise call from time to time GET on the URL to get all the data.

Why there needs to be a different protocol for calendar subscription feeds, different from the regular calendar
transport protocols?

On another note, about VJOURNAL, https://tools.ietf.org/html/rfc5545#section-3.8.1.11 says for STATUS:

   Description:  In a group-scheduled calendar component, the property
      is used by the "Organizer" to provide a confirmation of the event
      to the "Attendees".  For example in a "VEVENT" calendar component,
      the "Organizer" can indicate that a meeting is tentative,
      confirmed, or cancelled.  In a "VTODO" calendar component, the
      "Organizer" can indicate that an action item needs action, is
      completed, is in process or being worked on, or has been
      cancelled.  In a "VJOURNAL" calendar component, the "Organizer"
      can indicate that a journal entry is draft, final, or has been
      cancelled or removed.

Possible value for VJOURNAL's STATUS: are DRAFT, FINAL and CANCELLED.

So the “cancelled or removed” stati above are both mapped to STATUS:CANCELLED.

However, the description above in the RFC does not say, that there is a status for removed in VTASK or VEVENT.

https://tools.ietf.org/html/draft-ietf-calext-subscription-upgrade-00#section-4.1 Redefined Status property contains
another:

   Description
      In a group-scheduled calendar component, the property is used by
      the "Organizer" to provide a confirmation of the event to the
      "Attendees".  For example in a "VEVENT" calendar component, the
      "Organizer" can indicate that a meeting is tentative, confirmed,
      or cancelled.  In a "VTODO" calendar component, the "Organizer"
      can indicate that an action item needs action, is completed, is in
      process or being worked on, or has been cancelled.  In a
      "VJOURNAL" calendar component, the "Organizer" can indicate that a
      journal entry is draft, final, or has been cancelled or removed.

There is no extra text to accomodate, that VEVENT and VTODO can also be “removed” ⇔ deleted.  “For example”
is not correct, as the text in the original RFC does try to describe all possible cases.  This shall be the intention of
the redefinition.

Regards
  Дилян

On Fri, 2019-06-07 at 08:43 -0700, [email-masked] wrote:
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify