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

[Michael Douglass <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify