Subject: [calsify] Removing the Protection from CALDAV:supported-calendar-component-set Property

From: Дилян Палаузов <[email-masked]>
Date: Tue, 23 Jul 2019 19:52:21 +0000

Hello,

RFC 4791 “Calendaring Extensions to WebDAV (CalDAV)”, Section 5.2.3. “CALDAV:supported-calendar-component-set Property”
defines supported-calendar-component-set as protected property: it cannot be changed by clients using a PROPPATCH
request.

What is the rationale for this?

For a calendar created before RFC 7953 “Calendar Availability” was invented, there is no way for the CUA to add support
for the VAVAILABILITY component afterwards.

I propose erratum to https://tools.ietf.org/html/rfc4791#section-5.2.3 CALDAV:supported-calendar-component-set Property

Type Technical

Current text:

Conformance:  This property MAY be defined on any calendar
      collection.  If defined, it MUST be protected and SHOULD NOT be
      returned by a PROPFIND DAV:allprop request (as defined in Section
      12.14.1 of [RFC2518]).

Description: … Any attempt by the client to store calendar object resources with
      component types not listed in this property, if it exists, MUST
      result in an error, with the CALDAV:supported-calendar-component
      precondition (Section 5.3.2.1) being violated.  Since this
      property is protected, it cannot be changed by clients using a
      PROPPATCH request.  However, clients can initialize the value of
      this property when creating a new calendar collection with
      MKCALENDAR. …

New text:

Conformance:  This property MAY be defined on any calendar
      collection.  If defined, it MAY be protected and SHOULD NOT be
      returned by a PROPFIND DAV:allprop request (as defined in Section
      12.14.1 of [RFC2518]).

Description: … Any attempt by the client to store calendar object resources with
      component types not listed in this property, if it exists, MUST
      result in an error, with the CALDAV:supported-calendar-component
      precondition (Section 5.3.2.1) being violated.  Clients can initialize
      the value of this property when creating a new calendar collection with
      MKCALENDAR. …

Rationale: The protected status of supported-calendar-component-set is removed, so that CUAs can add component types to
existing callendars, which component types were not defined, when the calendar was created

Plese provide feedback within a month, afterwards I will submit it over https://www.rfc-editor.org/errata_report.php .

What will happen then?  What are the chances, that nothing happens, and therefore the time for submitting this is
practically lost.

Regards
  Дилян

---

From: Michael Douglass <[email-masked]>
Date: Wed, 24 Jul 2019 15:02:18 -0400

> What is the rationale for this?

I think the rationale is that once a calendar is populated you can't be 
changing the allowable component types - or at least it gets very 
complicated.

What if you try to change it from tasks + events to events + 
availability while it contains tasks and events?

And what about clients that may have made decisions based on the 
allowable types?

The move was away from mixed types anyway.

> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Дилян Палаузов <[email-masked]>
Date: Thu, 25 Jul 2019 06:55:35 +0000

Hello Michael,

when changing from events+todos to events+availability on a collection containging tasks, the server returns error and
changes nothing.

Clients that made decisions based on allowable types... caldav collection properties like displayname, transparency,
description, color can change and clients are supposed to be able to refresh the values from the server.  Likewise, when
the values in supported-calendar-component-set change, clients adapt.

Regards
  Дилян