Cyrus CalDAV design decision

Robert Mueller robm at
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
> implementations.

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
    client implementation.

 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
    inadequately described:

 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
pretty bad.

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?



Rob Mueller
robm at

More information about the Cyrus-devel mailing list