HTML Body in kolab.xml?

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at
Mon Nov 22 22:29:23 CET 2010

On Monday, November 22, 2010 12:04:54 am Shawn Walker wrote:
> On 11/21/2010 3:36 AM, Jeroen van Meeuwen (Kolab Systems) wrote:
> > On Saturday, November 20, 2010 06:05:45 pm Shawn Walker wrote:
> >> Is it possible to add another XML tag to the Kolab spec "htmlbody"? The
> >> reason is that Outlook allow the user to style the body of event, tasks,
> >> contacts, etc. Currently "body" tag is only for plain text.
> >> 
> >> I think we should also BASE64 encode the HTML text for "htmlbody" to
> >> remove any issues with the HTML tag interfering with the XML tag.
> >> 
> >> <htmlbody>base64_encoded</htmlbody>
> > 
> > I like the feature, but here's a thought, further enhancing the idea;
> > 
> > The HTML body would not have to be part of the Kolab XML payload, and can
> > just be an attachment. The ability for a client to display the HTML body
> > (instead of?) the plaintext body could then be based on referrals to a
> > specific attachment, not locking in the XML format itself to HTML
> > content specifically. Attachments that (in the future?) could then be
> > displayed inline could include formats such as ODF, PDF, GS, ...
> > etcetera. I propose considering something along the lines of
> > <formattedbody attachment="$reference" />.
> In Outlook, there are three properties for the body of the message, plain
> text, html and RTF.  We can ignore the RTF since there will be a html body
> (let's hope and I have never seen an instance where there was not a html
> body if the user created a formatted body).
> Having "formattedbody" is fine.  Probably should allow more than one
> "formattedbody" tags to that there can be multiple version of the body but
> that "attachment="$reference"" must be included so that the client can
> choose which formatted body it can handle.

Agreed, whether a "formattedbody" element is used, possibly with an attribute 
to indicate the language used to format the body, or an attachment is being 
referred to is a relatively small detail.

I would ultimately hope, though, attachments in the IMAP backend can be de-
duplicated, and would therefor argue that if it is not all too much trouble to 
implement now, it would be worth looking at using attachments -with those 
formats that are generally read-only like PDF, this becomes more significant. 
That said, however, I do not think whether attachments or formattedbodies 
should be a show-stopper.

The former notwithstanding, all clients already handle attachments to Kolab 

> The only issue with having multiple formats is if the client doesn't
> understand the format, but does update the plain text, then the bodies in
> the kolab data will get out of sync.

I would, for the case you state here, attempt to implement a clause in the KEP 
along the lines of:

  "If a Kolab XML formattedbody exists, the client MUST be capable of updating 

This could still be valid for clients not understanding the HTML format for 
the case that originally started this thread, but would at least provide the 
HTML formatted body with a (non-HTML?) string.

I would appreciate your feedback on the latter, because it would compromise -
to some extent- some of the purpose of saving a formatted body to begin with.

Kind regards,

Jeroen van Meeuwen

Senior Engineer, Kolab Systems AG

e: vanmeeuwen at
t: +316 42 801 403

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the format mailing list