]> Spherical Cow Group

226 3rd Street Troy NY 12180 USA mdouglass@sphericalcowgroup.com http://sphericalcowgroup.com

Applications icalendar properties This specification introduces an approach to allow subscribers to calendar feeds to upgrade to a more performant protocol.

Currently clients subscribe to calendar feeds as an ics file which is often published as a resource accessible using the unofficial 'webcal' scheme. The only available option for updating that resource is the usual HTTP polling of cached resources using Etags. There is the usual tension between clients wishing to see a timely response to changes and servers not wishing to be overloaded by frequent requests for possibly large amounts of data. This specification introduces an approach whereby clients can discover a more performant access method. Given the location of the resource as an ics file, the client can perfom an OPTIONS request on the resource and inspect the returned headers which will offer a number of alternative access methods. Given that many clients already support CalDAV this provides an easy upgrade path for those clients. CalDAV and DAV subsets are specified here to allow lighter weight implementations.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This specification does not require any changes to or its extensions. However it does introduce the use of some properties to provide more information about the resource, for example the time range it covers.

The advertising of other access points is achieved through the use of the LINK header as defined in . New link relation types are defined in this specification - each being associated with a protocol or protocol subset. These LINK headers will be delivered when a client carries out an OPTIONS request targeting the URL of the resource.

This specifies an access point which is a full implementation of caldav but requires no authentication. The end point allows the full range of reports as defined by the CalDAV specification. The client MUST follow the specification to determine exactly what operations are allowed on the access point - for example to determine if sync-report is supported. The URL MAY include some form of token to allow write access to the targeted collection. The client must check it's permissions to determine whether or not it has been granted write access.

This specifies an access point which is a full implementation of caldav and requires authentication. This may allow read-write access to the resource. The client MUST follow the specification to determine exactly what operations are allowed on the access point - for example to determine if sync-report is supported.

This specifies an access point which supports only webdav sync. This allows the client to issue a sync-report on the resource to obtain updates. NOTE: say something about initial startup - use ics to populate? Initial token? The client MUST follow that specification.

This specifies an access point which supports something new. The client MUST follow that specification.

Applications using these properties need to be aware of the risks entailed in using the URIs provided as values. See [RFC3986] for a discussion of the security considerations relating to URIs.

Properties with a "URI" value type can expose their users to privacy leaks as any network access of the URI data can be tracked. Clients SHOULD NOT automatically download data referenced by the URI without explicit instruction from users. This specification does not introduce any additional privacy concerns beyond those described in .

This document defines the following new iCalendar properties to be added to the registry defined in Section 8.2.3 of : Relation Name Description Reference subscribe-caldav Current RFCXXXX, subscribe-caldav_auth Current RFCXXXX, subscribe-webdav-sync Current RFCXXXX, subscribe-something-else Current RFCXXXX,

The author would also like to thank the members of the Calendaring and Scheduling Consortium Calendar Sharing technical committee and the following individuals for contributing their ideas and support: ... The authors would also like to thank the Calendaring and Scheduling Consortium for advice with this specification.

&RFC2119; &RFC2434; &RFC3688; &RFC3986; &RFC4589; &RFC5545; &RFC5546; &RFC5988; &W3C.REC-xml-20060816; &I-D.ietf-calext-extensions;

Need to determine what if any registry of resource types already exists and use that.

v01 2017-17-02 MD Add text abut OPTIONS Add text abut read/write CalDAV v00 2017-15-02 MD First pass