[Kolab-devel] CalDAV Collections vs. IMAP Folders

[Thomas Brüderli]

Hello devs

While working on the CalDAV/CardDAV service for Kolab I came across a
small contradiction between the way CalDAV handles collections and the
IMAP folder structure Kolab is built upon.

First thing is, that the CalDAV clients respectively) don't work with a
hierarchical structure of collections. Also the SabreDAV library doesn't
support that right away. Thus, my straight forward approach to advertise
calendar folders as CalDAV collections was to simply use their full path
(e.g. "Calendar/Personal Calendar") as the UID and the display name for
them. That works perfectly fine for synchronization.

But once actual collection management over the CalDAV protocol comes
into the game, that simple matching isn't enough. CalDAV uses UIDs to
identify collections and display names to list them in the UI. So what
do we do when somebody wants to rename a calendar from their CalDAV
client? On the IMAP server side there is UID = display name = IMAP
folder path. If the UID is derived from the IMAP path, it changes when I
rename a folder, and even worse, it changes for subfolders when I rename
their parent folder. That's definitely not a "unique" identifier.
Another problem is to map the new name of a *DAV collection, submitted
by the client, into a folder hierarchy. Because there's no hierarchy in
*DAV resources, the names are simple strings. Of course we can "guess"
the structure by using chars like "/" or ":" or anything else as
hierarchy indicators but that's not really deterministic. And even if we
do that, by renaming a folder, it's UID implicitly changes, too.
Therefore, requests from the client, subsequent to a renaming operation
will fail because the requested collection (identified by its UID) isn't
found. The client will most likely display an error message and
eventually re-sync the entire resource list which results an a complete
cache invalidation and all objects have to be transferred again.

And it gets even worse for collection creation. Apple iCal for example,
generates random UIDs for new calendars and then sets the display name
property to whatever the user enters. So far I didn't find a way to tell
the client, that collection X has moved to Z. And we definitely don't
want calendar folders to appear as 64-character UIDs in the web client
either.

But we're not done yet! Think of a shared calendar, which we see as
"shared/Some Calendar" in IMAP. For CalDAV, the display name could be
something like "shared/Some Calendar" or "shared » Some Calendar". If
the user now decides to rename it to "Some shared calendar", we cannot
move it to the personal namespace. So the Kolab Server will either
ignore or reject or alter the new name. It's hard to make rules for a
reasonable behavior in this case.

Now, how to bring these two concepts together? I see different scenarios:

1) Do not allow collection management via *DAV at all. Problem solved.
Once can use the web client to manage folders AKA collections.

2) We use IMAP metadata to store UIDs for folders which are then used to
provide unique urls for *DAV clients. A UID will be generated on the
first access via the DAV protocol.

2a) The display name is derived from the IMAP folder path and is
immutable (except when creating new folders).

2b) The display name is also stored in IMAP metadata and can be modified
as a simple attribute.

I admit, none of the above scenarios is perfect. 1) works for simple
synchronization purposes where the client "subscribes" to a collection
as we see it in Thunderbird. But it limits the interaction with
sophisticated clients such as Apple iCal. 2a) doesn't provide a nice
user experience either but at least it allows to create and delete
collection. And 2b) may result in diverging names of collections/folders
when using multiple clients.

I guess we can all agree that storing UIDs as IMAP annotations can
easily be implemented without major side-effects. But any suggestions
how to solve the display name issue are much appreciated.

Thanks for listening!

~Thomas