Kolab 3.0 Storage Format

From Kolab Wiki

Jump to: navigation, search
This page applies to Kolab 3.
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

This page lines out how Kolab Objects are stored on a Kolab IMAP Server (Kolab Version 3.x).



Each Kolab Object is stored as XML object according to #KEP 17 in a Mime-Message which itself is stored in the appropriate folder on the IMAP server.

The following types of Kolab Objects exist:

  • calendar
  • task
  • journal
  • contact
  • note
  • configuration
  • freebusy
  • file

Note that distribution lists are also stored in the contact folder.


Two libraries currently exist implementing the Kolab 3.0 Storage Format:

  • libkolabxml: Implements the XML storage format [libkolabxml]
  • libkolab: Implements the MIME storage format [libkolab]

Helper Tools

Both libkolabxml and libkolab contain a validator allowing to validate single xml files (libkolabxml) respectively MIME messages (libkolab). Building of the tools is controlled by the BUILD_UTILS cmake switch and the code is in the utils/ directory.

Kolab Folders


  • The difference between ANNOTATEMORE (the draft) and METADATA (the RFC) doesn't matter for the verbiage of this part of the format definition.
  • The shared scope for annotations SHALL be /vendor/kolab/ value.shared in ANNOTATEMORE, /shared/vendor/kolab/ in METADATA
  • The private scope for annotation SHALL be /vendor/kolab/ value.private in ANNOTATEMORE, /private/vendor/kolab/ in METADATA
  • All folders with Kolab Groupware content MUST be annotated with their respective groupware type.
    • The shared scope SHALL be used for groupware types:
      • "event"
      • "journal"
      • "task"
      • "note"
      • "contact"
      • "configuration"
      • "freebusy"
      • "file"
    • The groupware type MUST not be altered at any time.
    • The groupware type SHALL be stored using the "/vendor/kolab/folder-type" metadata location when using METADATA.
    • One groupware folder per groupware type MAY be marked as default location for new kolab-objects by adding a private annotation with the suffix ".default".
  • Folders with mail content MAY exist without metadata.
  • Folders without any metadata MUST be treated as mail folders.
  • Folders with an unrecognized folder-type annotation SHALL NOT be displayed to the user as containing normal mail data.
  • Mail Folders MAY be annotated using the value "mail".
  • Mail Folders with a special purpose SHOULD be annotated in the private scope using the value "mail" with one of the following suffixes:
    • ".inbox"
    • ".drafts"
    • ".sentitems"
    • ".outbox"
    • ".wastebasket"
    • ".junkemail"

There SHOULD always exist only one "default" folder per groupware type.

  • A "default" folder in the private IMAP namespace takes precedence over any other.
  • In case of multiple "default" folders within the private IMAP namespace or none in the private but multiple in the shared IMAP namespace clients SHOULD pretend no folder has been marked as "default".


  • Kolab Folders MAY be located anywhere in the IMAP account.
    • The MAY be toplevel, in INBOX, in the shared namespace, nested within non-kolab folders.
  • If there are multiple folders of the same type:
    • Each folder SHALL be interpreted as separate group, allowing the user to select where to store a new object (if the client supports that). Examples for interpretations are:
      • calendars
      • tasklists
      • notebook/folder
      • addressbook
    • subfolders SHOULD be interpreted as such (subcalendar, sub-addressbook, ....)
  • TODO: we probably should have a bit a firmer specification how multiple folders SHOULD be interpreted for each type to get a consistent user experience.

Mime Message Format

Each Kolab object MUST be stored in its own MIME Message. The email uses a multipart/mixed structure, with the following parts:

  • A text body part with a fixed text telling about Kolab.
  • The XML describing the object.
  • Other attachments, like a contact’s picture or the attachments associated with e.g. a note or event.

The following mime-headers are used:

  • Subject: MUST be set to the UID of the object (The primary purpose for this is searching).
  • Date: SHALL be updated every time the MIME message is written, with the current timestamp in UTC.
  • From: MAY contain the organizer of the incidence as encoded address (John Doe <doe@kolab.org>).
  • User-Agent: SHALL identify the software used to generate the MIME message
  • Content-Type: MUST be "multipart/mixed"
  • X-Kolab-Type Header: Identifies the Kolab Object Type. This header is REQUIRED. Possible values are:
    • application/x-vnd.kolab.event
    • application/x-vnd.kolab.task
    • application/x-vnd.kolab.journal
    • application/x-vnd.kolab.contact
    • application/x-vnd.kolab.distribution-list
    • application/x-vnd.kolab.note
    • application/x-vnd.kolab.configuration
    • application/x-vnd.kolab.file
  • X-Kolab-Mime-Version: Contains the Kolab MIME Format Version. This header is REQUIRED.
  • X-Kolab-Conflict: Holds the CID of a previous conflicting version, which has been resolved to this current version. This header is OPTIONAL. See Conflict Resolution.


This version number specifies the format version of the MIME-Message and not the embedded XML object.

  • The version number MUST be compared using stringcomparison and MUST NOT be converted to a number.
  • The only currently valid version number is "3.0".
  • Future version may introduce a teeny version number in the form of "x.y.z",

Text Body Part

The text body part is there so non-kolab clients which display the message as normal email show a message that this is a Kolab Object. The text should ideally indicate where to get a Kolab Client. The following text is proposed:

This is a Kolab Groupware object.
To view this object you will need a Kolab Groupware Client.
For a list of Kolab Groupware Clients please visit:
  • The text body part MUST always come first.
  • The following headers/options MAY be used :
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
This part is purely informal, and a client may change it to whatever is deemed most suitable (different encodings/charsets/text)

XML Object Part

This part contains the Kolab XML Object.

  • This part MUST always come second (directly after the Text Body Part).
  • The following headers/options MUST be used:
Content-Type: MIMETYPE; name="FILENAME"
Content-Transfer-Encoding: ENCODING
Content-Disposition: attachment; filename="FILENAME"
  • MIMETYPE MUST be one of (as specified in KEP #17):
    • application/calendar+xml
    • application/vcard+xml
    • application/vnd.kolab+xml
  • FILENAME SHALL be any name for the kolab xml object. "kolab.xml" is suggested.
  • ENCODING SHALL be "quoted-printable"
    • Other encodings MAY be chosen, if there is a good reason to do so
    • quoted-printable SHALL be used to ensure maximum interoperability (all clients need to be able to deal with the encoding)

Attachment Parts

Large binary objects (e.g. pictures or attachments) SHOULD be stored as separate MIME-Part, and only be referenced from the XML object using its cid (Content-ID). This is to allow clients to fetch those (potentially large) objects on demand only.

  • The attachment-part MUST be referenced and retrieved by it's CID.
    • using the name-header or alike is explicitly not supported.
  • Attachment-parts which are not referenced (from the Kolab XML Object or a header) SHALL be removed.
  • The following headers/options MUST be used:
Content-ID: <CID>
Content-Type: MIMETYPE; name=FILENAME
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=FILENAME; size=SIZE
  • The FILENAME is optional for all object types except the "file" objecttype, but often used by email clients to display the attachment to the user (This helps to extract parts of a Kolab Object using a normal email client)..
    • This property should typically be the same as the label property stored in the Kolab Format attachment property
    • For attachments which are just kolab object properties, such as a contact logo, a descriptive name such as logo.png SHOULD be chosen.
    • See http://www.imc.org/ietf-smtp/mail-archive/msg05023.html for more info.
  • The CID MUST be a (usually random) string according to the provisions set forth in http://tools.ietf.org/html/rfc1521.
  • The CID SHALL be preserved if an attachment has not changed, this allows clients to not redownload attachments that have not changed.
    • The CID MUST change if the attachment has been changed/modified.
  • The SIZE is optional for all object types except the "file" objecttype. It contains the filesize of the unencoded (extracted) attachment in octets (bytes), and is used to be displayed to the user. (See http://www.ietf.org/rfc/rfc2183.txt for more information on the size parameter)
  • filename and size properties are required for the file objecttype


 Date: Mon, 23 Apr 2012 12:37:59 +0200
 X-Kolab-Type: application/x-vnd.kolab.event
 X-Kolab-Mime-Version: 3.0
 User-Agent: Libkolab-0.1.0
 Content-Type: multipart/mixed; boundary="nextPart1929983.SbWkbbbi0G"
 Subject: KOrganizer-1687167952.818
 MIME-Version: 1.0
 Content-Type: text/plain; charset="us-ascii"
 Content-Transfer-Encoding: 7Bit
 This is a Kolab Groupware object.
 To view this object you will need an email client that can understand the Kolab Groupware format.
 For a list of such email clients please visit
 Content-Type: application/calendar+xml; name="kolab.xml"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment; filename="kolab.xml"
 <?xml version=3D"1.0" encoding=3D"UTF-8" standalone=3D"no" ?>
 <icalendar xmlns=3D"urn:ietf:params:xml:ns:icalendar-2.0">
         <text>Libkolab-0.1.0 Libkolabxml-0.3.0</text>
             <text>Complex Event</text>
             <text>Some notes on this event.</text>
 Content-ID: <7313173.zaagFSsPPv@kolab.resource.akonadi>
 Content-Type: image/png; name="akonadi.png"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename="akonadi.png"
Personal tools