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

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

On Wed, 2019-07-24 at 15:02 -0400, Michael Douglass wrote:
> On 7/23/19 15:52, Дилян Палаузов wrote:
> > 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?
> 
> 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.
> 
> > 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
> >    Дилян
> > 
> > _______________________________________________
> > calsify mailing list
> > calsify@ietf.org
> > https://www.ietf.org/mailman/listinfo/calsify
> 
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify