This specification defines a model for streaming calendar and contact data. This allows for a more efficient method for synchronizing collections of data and may be used to augment existing protocols such as CalDAV.
© 2018 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 defines a model for streaming calendar and contact data. This allows for a more efficient method for synchronizing collections of data and may be used to augment existing protocols such as CalDAV.
Currently clients or servers maintain a synchronized copy of external data through subscriptions and polling or by the use of protocol extensions such as DAV Sync Report.
These methods in essence require polling at more or less regular intervals to detect changes. For more timely detection of changes, frequent polling is required. This leads to inefficiencies and costs in battery and network usage.
The situation may be improved by the use of push notifications but this adds complications to the system.
This specification introduces an approach whereby a clients opens streams and then simply writes to or reads from the stream. This is not conceptually a new invention. Messaging systems already provide such features. What this specification provides is the data structures which can be passed as messages and defines the allowable operations.
This specification will provide an approach to implementations using websockets or currently existing messaging systems such as JMS.
This specification defines a model for streaming calendar and contact data. This allows for a more efficient method for synchronizing collections of data and may be used to augment existing protocols such as CalDAV.
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
This specification assumes that there are two virtual streams open for each established virtual connection: an output stream and an input stream.
All operations are carried out by either end writing a message on the output stream and receiving an acknowledgment on the input stream.
All messages MUST receive an acknowledgement within the defined timeout period or they or their acknowledgement will be assumed to have been lost. The sender will need to carry out any appropriate recovery.
Each message sent MUST include a unique (within the connection) identifier which will be returned in the acknowledgment.
The actual systems on which this is running may have many restrictions. Connections may be forcibly shut down after some idle time and there will be the usual issues with mobile devices and connectivity.
The virtual connection MUST hide these issues from the client. A connection will last until one end is deemed to have shut down the connection.
On subsequent conditional fetches the entity will not be returned.
This is an example of the initial request and response from a server that supports the extended GET protocol.
This is an example of the subsequent request and response when no changes have occurred. The Accept header field indicates that a VPATCH format is most desirable but simple text/calendar is acceptable.
This is an example of the subsequent request and response when changes have occurred and the server can create the minimal format.
This is an example of the subsequent request and response when changes have occurred and the server cannot create the minimal format — perhaps because of an old or invalid token. Note there is no Preference-Applied header field.
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, cancelled, or deleted. In a “VTODO” calendar component, the “Organizer” can indicate that an action item needs action, is completed, is in process or being worked on, has been cancelled, or has been deleted. In a “VJOURNAL” calendar component, the “Organizer” can indicate that a journal entry is draft, final, cancelled, or deleted.
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:
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 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. Initial startup may require using ics to populate and obtain initial token.
The client MUST follow that specification.
This specifies an access point which supports enhanced GET functionality as defined in this specification.
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
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
| Relation Name | Description | Reference |
|---|---|---|
| subscribe-caldav | Current | RFCXXXX, |
| subscribe-caldav-auth | Current | RFCXXXX, |
| subscribe-webdav-sync | Current | RFCXXXX, |
| subscribe-enhanced-get | Current | RFCXXXX, |
The author would also 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
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 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 creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. [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]