Cyrus CalDAV design decision
robm at fastmail.fm
Wed Sep 7 00:45:37 EDT 2011
(Resending to include cyrus-devel)
> > At the moment, the storage format in use is iCalendar, being stored as
> > RFC5322 messages.
> That sounds very much like what Kolab did in version 1.
> After trying to make this interoperate for several years it was given
> up in favor of the Kolab XML format because iCalendar & vCard looked
> good on paper but suffered from severe interoperability issues between
While I like the idea of the Kolab format, I'd like to point out that
it's not all quite as rosy as you suggest. Most the criticisms you have
of iCalendar and vCard, the Kolab format has equal amount of or more.
Having had a look at the spec and putting together comments from several
1. The format never seems to have ever made it to the "finished" state.
It's been stuck in RC states for several years. I don't think that
gives strong confidence to implementers that it's actually stable.
2. The description is that's it's in XML, but there's no DTD or ABNF,
just a pseudo english format description. So there's no way to
clearly test that you can create/read conforming XML blobs in a
3. The document is very incomplete in places, for example this node:
4. It's also inconsistent in places. Some attributes being described as
both "MAY be present" and "mandatory":
5. Some parts are underspecified. The "sensitivity" field is
6. For that matter, there's no complete set of examples (an mbox full
of example Events, Tasks, Contacts, etc) or a test suite that
clients should be able to read and interoperate with.
7. The Datetime format seems arbitrarily made up, but is actually the
ISO8601 combined extended UTC format with second precision, but you
don't reference ISO8601 or RFC3339 which also defines "Internet
time" the same way. Likewise Date.
8. Recurrence seems primitive. Recurrence across DST boundaries seems
to be as broken as every other format. There doesn't seem to be a
way to specify public holiday exclusions.
9. The docs talk about ANNOTATEMORE more everywhere, which really needs
updating to include METADATA and the final RFC
10. The /vendor/kolab/folder-type annotation should be updated now that
SPECIALUSE has been made an RFC
When you add these things together, I don't think it makes it easy to
create a client or server for the Kolab format.
And I think that goes part of the way to explaining why the quality of
alternate clients out there hasn't exactly been great. I've tried Bynari
(Outlook) and SyncKolab (Thunderbird), and their implementations are
Having said a bunch of negative things, let me finish on how I think we
can actually fix these and take these forward:
1. The Kolab Format spec needs to be completely finished. Edge cases
cleaned up, todo parts finished, and unspecified bits specified
2. It needs to be marked as a true 2.0 version, not an RC. You can add
2.1 later if you want, but I think the eternal RC status just leaves
it feeling abandoned.
3. We need some sort of test suite/code. That should consist of at least
two main things:
a) A large bunch of emails that test all the different edge cases of
the spec that clients should be able to read provided in a simple
mbox format (separate one for each folder type). That way at least
client implementers can quickly test their reading code against a
bunch of cases
b) Some standalone C/C++ executable that should be able to read these
emails, check they conform to the right format, and dump a memory
structure of the parsed result. That will allow implementers to
quickly check that they're generating correctly formatted data
Yes, that would require a bit of work from someone, but I totally think
it's worth it, and I think it would go a long way to helping more
implementers work on the Kolab format in the future.
What do you think the chances are of dedicating a developer or two for a
few months to actually getting the spec up to scratch, and building the
above 3a and 3b testing sets/tools?
robm at fastmail.fm
More information about the Cyrus-devel