Extra Header field

[Joon Radley]

Hi David,

> > > > > I like the idea because it speeds up the common case. But I 
> > > > > think that the header should only be a hint for 
> efficiency but 
> > > > > not a requirement.
> > > >
> > > > Well if there is no header it is treated as a RFC2822/non-Kolab 
> > > > message, so the XML format will be lost. It should be a 
> requirement.
> > > 
> > > Putting a requirement in a mail header is dangerious on one hand 
> > > (preserving headers is sometimes not guaranteed) and on 
> the other I 
> > > don't understand why in the case of the missing extra 
> header the XML 
> > > format gets lost.
> > 
> > Three storage use cases:
> > 1) Single body part mail, where content-type is set to 
> > application/x-vnd.kolab.*.
> Is this even supposed to work? The storage format document 
> says the kolab-xml data should be an _attachment_. Which 
> means the mail is multipart/mixed, doesn't it?

No body has ever been defined. So I am making provision for content types of
application/x-vnd.kolab.*,
multipart/mixed and/or multipart/alternative.

The last one with a nice message stating that this is a Kolab formatted
message and the user can go to www.kolab.org/kolab-client.html for a list of
clients that support the kolab format.

Best Regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za