(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 people: 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. http://kolab.org/doc/kolabformat-2.0rc7-html/index.html 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: http://kolab.org/doc/kolabformat-2.0rc7-html/x180.html 4. It's also inconsistent in places. Some attributes being described as both "MAY be present" and "mandatory": http://kolab.org/doc/kolabformat-2.0rc7-html/c188.html 5. Some parts are underspecified. The "sensitivity" field is inadequately described: http://kolab.org/doc/kolabformat-2.0rc7-html/c188.html. 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 completely. 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 structures. 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? Cheers Rob Rob Mueller r...@fastmail.fm