© 2024 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 updates RFC5545 to add the value DELETED to the STATUS property.
This specification also adds values to the Preferences Registry defined in RFC7240 to add the subscribe-enhanced-get and limit preferences and to the link relations directory defined in RFC8288.
The Calendaring and Scheduling Consortium (“CalConnect”) is a global non-profit organization with the aim to facilitate interoperability of collaborative technologies and tools through open standards.
CalConnect works closely with international and regional partners, of which the full list is available on our website ().
The procedures used to develop this document and those intended for its further maintenance are described in the CalConnect Directives.
In particular the different approval criteria needed for the different types of CalConnect documents should be noted. This document was drafted in accordance with the editorial rules of the CalConnect Directives.
Attention is drawn to the possibility that some elements of this document may be the subject of patent rights. CalConnect shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be provided in the Introduction.
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
This document was prepared by Technical Committee FREEBUSY.
Currently, clients subscribe to calendar feeds as an iCalendar file which is often published as a resource accessible using the unofficial ‘webcal’ URI scheme.
The only available option for updating that resource is the usual HTTP polling of cached resources using
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 iCalendar file, the client can perform a HEAD request on the resource and inspect the returned headers which will offer a number of alternative access methods.
Given that many clients and servers already support CalDAV this provides an easy upgrade path for those clients. Additionally, an enhanced GET protocol is specified here to allow a lightweight implementation.
The use of subscription upgrade may help reduce load on servers, but perhaps more importantly it allows mobile devices to use a more efficient update mechanism, reducing data transferred and presumably improving battery life.
This document provides a mechanism to allow subscribers to calendar feeds to upgrade to a more performant protocol.
The advertising of other access points is achieved through the use of the LINK header as defined in
These LINK headers will be delivered when a client carries out a HEAD request targeting the URL of the resource.
This is an example of a HEAD request and the response from a server that supports the enhanced GET method.
Note that the target for an upgraded service may be the same as for the initial resource.
This is a lightweight protocol which allows simple clients to efficiently discover and download changes in the targeted resource.
It has many similarities to
In this protocol the client MUST include the Prefer header field preference “subscribe-enhanced-get”. If a sync token is available it is passed as a Sync-Token header field.
The resource is treated as a set of individual events each of which may be updated or deleted separately. Note that a recurring event and its overrides are treated as a single entity. The client will first fetch the entire iCalendar file. On subsequent requests it uses the Prefer header field and a Sync-Token header field to indicate that it wants a set of changes since the last fetch.
If no Sync-Token header field is supplied the server MUST respond with a full set of data and SHOULD set the Preference-Applied header field and a new Sync-Token header field value.
If the token is valid, it SHOULD return with a set of changed entities and MUST set the Preference-Applied header field and a new Sync-Token header field value.
When a server receives an invalid token it MUST return a 409 status (Conflict). The server MAY choose to return an error message in the body.
The client MUST respond to this error by discarding the cached data and restarting the interaction from scratch, i.e. retrieve the full set of data then poll for updates.
In the absence of a Prefer header field, the server MAY include the Sync-Token header field. This can act as a signal to the client that the server supports the enhanced-get protocol.
When an entity (VEVENT, VTODO or other valid top-level component) is deleted from the source data the server needs to be able to inform a client of the deletion. This specification introduces a new value “DELETED” for the
On the first enhanced GET after the entity has been deleted a skeleton, but valid, entity will be returned with STATUS: DELETED. The receiving client is free to remove the entity or update its STATUS property.
On subsequent fetches the entity will not be returned.
As noted above, the skeleton entity returned must be a valid component as defined by the specifications. For example, a VEVENT MUST contain the DTSTAMP, DTSTART and UID properties as well as the STATUS: DELETED property. The DTSTAMP and DTSTART may be generated and the UID MUST be the UID of the deleted entity.
A client may explicitly request a limit on the size of the response by specifying the Prefer header field preference “limit=n” where n is the number of components.
When a server receives a request specifying such a limit it SHOULD limit the response to that number of components. If the limit causes a truncation in the response the server should respond with a Preference-Applied header specifying the limit that was applied and return a sync token which may be used to retrieve the next batch of data.
This allows the client to immediately resubmit a request for the next batch using the updated token.
A server MAY choose to limit the response size. The behavior MUST be as if the client had provided a preference for that size - allowing the client to retrieve the full set of data in batches.
Note that the process above assumes that the current position in the resource is encoded in some way within the sync token.
To enable proper caching of responses the server SHOULD provide a Vary header field defined in
See
This is an example of the initial request and response from a server that supports the enhanced GET method. Note the use of the Vary header so a caching proxy can key off the client’s Sync-Token and preference.
This is an example of the subsequent request and response when no changes have occurred.
This is an example of the subsequent request and response for an old or invalid token.
This is an example of the subsequent request and response when changes have occurred.
This specification updates
STATUS
This property defines the overall status or confirmation for the calendar component.
TEXT
IANA and non-standard property parameters can be specified on this property.
This property can be specified once in “VEVENT”, “VTODO”, or “VJOURNAL” calendar components.
In a group-scheduled calendar component, the property is used by the “Organizer” to provide a confirmation of the event to the “Attendees”. For example in a “VEVENT” calendar component, the “Organizer” can indicate that a meeting is tentative, confirmed, or cancelled. In a “VTODO” calendar component, the “Organizer” can indicate that an action item needs action, is completed, is in process or being worked on, or has been cancelled. In a “VJOURNAL” calendar component, the “Organizer” can indicate that a journal entry is draft, final, or has been cancelled or removed.
This property is defined by the following notation:
The following is an example of this property for a “VEVENT” calendar component:
The following is an example of this property for a “VTODO” calendar component:
The following is an example of this property for a “VJOURNAL” calendar component:
This specification defines a new header field Sync-Token for use by the enhanced GET method.
The value MUST be a URI which could be a data URI. The synchronization token itself MUST be treated as an “opaque” string by the client, i.e., the actual string data has no specific meaning or syntax. These restrictions align the specification with
This is an example of the Sync-Token header field:
This indicates that the client expects the server to handle the GET method according to the specifications for enhanced get.
This preference parameter provides a limit on the number of components returned for enhanced get.
This clause defines a number of new link relations required to facilitate subscription upgrades.
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 DAV:sync-collection is supported.
The URL MAY include some form of token to allow write access to the targeted collection. The client must check its permissions to determine whether 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 DAV:sync-collection is supported.
This specifies an access point which supports only
This allows the client to issue a DAV:sync-collection report on the resource to obtain updates.
The client MUST follow the requirements of
This specifies an access point which supports the enhanced GET protocol defined in
The client and server MUST follow the protocol as defined in
Applications using these properties need to be aware of the risks entailed in using the URIs provided as values. 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
This specification updates the “Message Headers” registry entry for “Sync-Token” in
The following preferences have been added to the HTTP Preferences Registry defined in
subscribe-enhanced-get
None.
Marks the interaction as enhanced get and provides the optional sync-token and page size.
this document
limit
An integer page size.
Provide a limit on the number of components in the response.
this document
The following link relation values have been added to the Reference Types Registry defined in
| Relation Name | Description | Reference |
|---|---|---|
subscribe-caldav |
Current |
|
subscribe-caldav_auth |
Current |
|
subscribe-webdav-sync |
Current |
|
subscribe-enhanced_get |
Current |
This specification updates
This specification updates
| Name | Status | Reference |
|---|---|---|
CANCELLED |
Current |
|
COMPLETED |
Current |
|
CONFIRMED |
Current |
|
DRAFT |
Current |
|
FINAL |
Current |
|
IN-PROCESS |
Current |
|
NEEDS-ACTION |
Current |
|
TENTATIVE |
Current |
This specification further updates the Status registry with the additional DELETED value defined in this document.
| Value | Status | Reference |
|---|---|---|
DELETED |
Current |
This Spec, |
The author would like to thank the members of the CalConnect Calendar Sharing technical committee and the following individuals for contributing their ideas and support:
Marten Gajda, Ken Murchison, Garry Shutler
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.
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 specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
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, “iCalendar Message-Based Interoperability Protocol (iMIP)”, specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]
This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) “calendar-access” feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the “calendar-auto-schedule” feature of CalDAV. [STANDARDS-TRACK]
This specification defines a model for the relationships between resources on the Web (“links”) and the type of those relationships (“link relation types”).
It also defines the serialisation of such links in HTTP headers with the Link header field.
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.
This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection. [STANDARDS-TRACK]