Extra Header field

[Joon Radley]

Hi Stuart,

> On Monday, 12 July 2004 15:48, David Faure wrote:
> > > 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?
> 
> Joon, didn't you say that we can't have this case to begin 
> with, as the body of a mail message has to be 7-bit encoded 
> (and the XML is UTF-8)?

Yes that was me. Since then I have realized that we defined the format, but
not the way it will be encapsulated in the MIME/RFC2822 message. How can you
define a multipart MIME type if you only have one body part(XML). In
reviewing the use cases of the MIME format I got a bit worried about the way
it will be implemented by other email clients.

So for the record lets propose an encapsulation:

1) The Kolab XML format is encapsulated in a multipart/alternative content
type as follows:

Content-type: multipart/alternative; boundary="STUPID-123456"

--STUPID-123456 
Content-type: text/plain; charset="us-ascii"

This is a Kolab Groupware object. To view this object you will need a email 
client that can understand the Kolab Groupware format. For a list of such
email clients please visit http:://www.kolab.org/kolab-clients.html 

--STUPID-123456
Content-type: application/x-vnd.kolab.note
Content-Transport-Encoding: base64

AABBDNNDKIJSGHGSHTUHAK==

--STUPID-123456--

2) When there are attachments associated with the object the message is
encapsulated in a multipart/mixed content type with the
multipart/alternative encapsulation described in 1 as the first body part in
the multipart.


Reads like a legal document. :-)

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