This specification provides a mechanism whereby subscriptions to external resources can be handled by the server.
This specification updates
© 2022 The Calendaring and Scheduling Consortium, Inc.
This document is not a CalConnect Standard. It is distributed for review and comment, and is subject to change without notice and may not be referred to as a Standard. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the address below.
The Calendaring and Scheduling Consortium, Inc.
4390 Chaffin Lane
McKinleyville
California 95519
United States of America
www.calconnect.org
This specification provides a mechanism whereby subscriptions to external resources can be handled by the server.
This specification updates
The motivation for this specification was initially to handle external subscriptions to calendar data. However, any resource which allows subscriptions might make use of this specification.
Currently subscriptions to calendar feeds are handled by calendar clients. There are a number of disadvantages to this approach: users have to subscribe from multiple devices and the subscription cannot affect scheduling handled by the server.
This specification defines a mechanism whereby the server will subscribe to the feed and make it visible in the user’s home.
The advantages are popular feeds can be cached by the server and the user only has to make a single subscription.
This specification provides a mechanism whereby subscriptions to external resources can be handled by the server.
This specification updates
No terms and definitions are listed in this document.
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
A client will subscribe to a URL by performing a MKCOL request with resource type elements of at least DAV:collection and DAV:subscription. For a calendar subscription there will also be a caldav calendar element.
This is an example of the MKCOL request and response from a server that supports extended MKCOL.
subscription
DAV
To indicate that the resource is a subscription to an external resource which is managed by the server.
When this is specified the request MUST also contain at least a DAV:subscription-href element as defined in this specification.
The DAV:specification resource type element is used to indicate a collection that is a subscription. A subscription MUST report the DAV:subscription XML element in the value of the DAV: resourcetype property.
subscription-href
DAV
Provides the url for the external subscription.
This property MUST be defined on any collection which has a resource-type containing a DAV:subscription element.
subscription-deletions-suppressed
DAV
To indicate that resources that no longer appear in the feed should be retained by the server.
This property MAY be defined on any subscription.
Many feeds provide only the current active set of resources. For example, a calendar feed may only contain events from the current date onwards - while many subscribers would like to retain a copy of all events received over time.
This property indicates that the server SHOULD retain resources that disappear from the feed. Services MAY define some mechanism to indicate that a particular resource SHOULD be removed. For example this specification suggests setting a status of DELETED on a calendar event.
subscription-disabled
DAV
To indicate that subscription has been disabled.
This property MUST be reported for any disabled subscription.
A server MAY choose to disable a subscription if there is an excessive number of errors when attempting to synchronize with the target This property indicates to the client that the subscription has been disabled.
There is no explicit action that can be taken to reenable a subscription. However, on subsequent requests a client may indicate a refresh is desired which MAY have the effect of reenabling the subscription.
subscription-next-refresh-interval
DAV
To indicate the time interval till the next refresh of a subscription.
This property MUST be reported for any active subscription.
This provides a time period to the next refresh. It uses the period format defined in
subscription-suggested-refresh-interval
DAV
To indicate the desired time interval between refreshes of a subscription.
This property MUST be reported for any active subscription.
This provides a suggested time period between refresh. It uses the period format defined in RFC 3339.
When creating the subscription the client may indicate to the server a desired refresh interval using the subscription-suggested-refresh-interval property.
The client may indicate to the server that a refresh of the data is desired by using the PROPPATCH method to set the subscription-next-refresh-interval to 0, e.g. “PT0S”.
A server MAY choose to always ignore the attempted refresh or to ignore the patch if it appears too often.
If the server decides to initiate a refresh it MAY choose to respond with a 102 HTTP status indicating that it is still waiting for the data or a 202 HTTP status to indicate the request was accepted.
Implementations of this feature may have an outboard or background process handling the actual synchronization of the data. The target may be hosted on a slow service or the data may be very large.
All these factors may lead to a significant delay in having data ready for delivery to the client.
The following approaches are more or less appropriate for handling requests:
This is the normal behavior. The subscription looks like a regular collection so the server can respond to the normal requests with whatever data is available.
If the synchronization process is active the server may just choose to wait. This risks a request timeout if the data synchronization takes a significant amount of time.
The server may choose to wait but periodically send a 102 response to keep the connection alive.
This is probably the best response. There is no need to indicate where the client should go to retrieve the data. All it needs to do is retry the operation after an appropriate delay.
As mentioned above, this feature is particularly useful for CalDAV servers and clients. There are some specific considerations.
If subscription-deletions-suppressed is specified then the server SHOULD retain all events. However, the server MAY choose to remove old events once they become older than the CALDAV:min-date-time property as specified in
A server SHOULD apply all appropriate restrictions on events obtained from a subscription. In particular the CALDAV:min-date-time and CALDAV:max-date-time properties as specified in
Additionally the CALDAV:max-resource-size property restricts the size of events and the CALDAV:max-instances property the number of instances.
Any reason not to allow them?
Servers implementing this feature need to be aware of the risks entailed in using the URIs provided as values to subscription-href. See
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
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 CalConnect, the Calendaring and Scheduling Consortium, for advice with this specification.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). [STANDARDS-TRACK]
This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the “calendar-access” feature of CalDAV. [STANDARDS-TRACK]
This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.
The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]
This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]
This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.