Extra Header field

[Joon Radley]

Hi Martin,

> > > 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.*.
2) Multipart mail, where content-type is set to multipart/*
3) Other content-type is set e.g. text/plain

Now in case (1) and (3) it is obvious from the header what type of message
this is. (1) is a kolab format and (3) is a non-kolab format(RFC2822).

Case (2) is the problem. Here you have to parse the entire message, look if
any one of the body parts are application/x-vnd.kolab.* type and only then
can you decide on the course of action. This can lead to double parsing of
the same message. 

By adding a X-KOLAB-OBJECT header field to the header all use cases are
satisfied by looking only at the header of the message. This header will
only be stored on the IMAP4 server for kolab formatted messages and should
never pass through a SMTP/LMTP gateway. 

By making the header optional you will have to parse all messages anyway
before you can make the final decision, which totally negates the purpose of
adding the header to the specification in the first place.

As for preserving headers, since when does Cyrus-IMAP discard headers? Can
you please provide me with the bug report so that I follow it up.

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