CalConnect Administrative

CC/A 1604:2016
Report on CalConnect Interoperability Test Event XXXVI, April 18-19, 2016
CalConnect Administrative




The Calendaring and Scheduling Consortium (“CalConnect”) is a global non-profit organization with the aim to facilitate interoperability of technologies across user-centric systems and applications.

CalConnect works closely with liaison partners including international organizations such as ISO, OASIS and M3AAWG.

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 ISO 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 of the 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 in the Introduction and/or on the CalConnect list of patent declarations received (see

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 IOPTEST.

Report on CalConnect Interoperability Test Event XXXVI, April 18-19, 2016

1.  Report

The Calconnect interoperability event was hosted by Ribose and OGCIO at Cyberport in Hong Kong on April 18 and 19, 2016.

The event at HongKong continued our move to a more forum like approach, combining testing of new and standard calendar features with a number of in-depth discussions.

The following organizations were attending

A major topic for this event - as for the last one - is trying to make iMip more reliable. In some cases it is the representation of the data which is the issue, other times it is incorrect handling of iTip.

Another topic which keeps coming back is dealing with differing interpretations of the iCalendar specification regarding recurrences.

2.  Discussions and issues raised

During discussions a number of issues were raised. These included:

2.1. Timezones

Do servers handle timezone definition changes - e.g. recalculate recurrences based on new timezone: the answer is usually not.


There was a proposal for adding an additional status to indicate “ARCHIVED”

Suggested alternatives: use different collection, or perhaps a structured category (this is also backwards-compatible, as opposed to a new status)

There is also a lack of rich text support - but that’s also true for events and tasks - this should also be addressed - see “Styled-Description” in

The general feeling is that JOURNAL is not heavily used.

2.3. Managed attachments

Problem: we cannot add an attachment right away together with an event with managed attachments - we would have to first add an event, than once it synced and we know the uid we can add an attachment.

2.4. Support for wiping devices (Raised by Marten from dmfs)

Do we need a special operation?

The way to go is to use per-device passwords (or OAuth to get device-specific markers) and return empty collections on the first sync.

This last point led to a discussion on client authentication and whether we could perhaps support open connect. See

3.  New API discussion

There is a new format proposal

Some of the api issues that were discussed were

On recurrences there was a discussion on the idea of excluding certain instances based on another event(s)

The start and end timezones are expressed through locations: first one corresponds to start, last - to end. The event timezone is independent.

4.  Issues found during testing

These included:

Missing timezones in ICS for single events.

When the recurrence rule doesn’t match the first start then some services silently move the first start to the first actual occurrence (which seems reasonable)

Moving a recurring instance into a different day did not work correctly.

Timezone customization is not set for events (at least recurring) sent through iMIP (although the timezone is saved).

Some clients were mishandling sequence numbers

Create a recurring event in the future, save and send invitations

Some servers don’t send invitations for past events even when the user is explicitly asked whether to send or not and says yes.

There were problems with autodiscovery

Some issues discovered and questions about Android clients:

Client iMip bug: invitations to single instances of a recurring event are not handled properly

Server iMip bug: Have a recurring event with one exception moved, then invite an attendee - the invitation only contains the series but not the exception

An interesting fact was noted: for recurring events where the recurrence doesn’t match the start date - between Apple, FastMail, Google and Open-Xchange these are all expanded differently (3 different behaviors).