RFC2822 windows attachment

Bernhard Reiter bernhard at intevation.de
Fri Jan 14 10:40:08 CET 2005


On Friday 14 January 2005 10:30, Till Adam wrote:
> On Friday 14 January 2005 09:22, Bernhard Reiter wrote:
> > On Friday 14 January 2005 06:59, Joon Radley wrote:
> > > > -----Original Message-----
> > > > From: kolab-format-bounces at kolab.org
> > > > [mailto:kolab-format-bounces at kolab.org] On Behalf Of Bernhard Reiter
> > > > Sent: Thursday, January 13, 2005 6:45 PM
> > > > To: kolab-format at kolab.org
> > > > Subject: Re: RFC2822 windows attachment
> > > >
> > > > I still would like to only have the custom data to save space.
> > > > Currently I would prefer having it in a X-Toltec-something
> > > > header base64 encoded header, but then again this is only my
> > > > limited knowledge on the subject.
> > > >
> > > > Joon: Does something speak against using such a header?
> > > > It might eben be easier for some tasks? Like searching for flags?
> > >
> > > The length of the header and the number of headers may present a
> > > problem. Firstly only a few of the properties are more than 20 bytes,
> > > but the larger once can be massive which might choke some clients.
> > > There is no actual length limit on a header field, but it could be
> > > tricky. Secondly it can add a large number of headers to the e-mail.
> >
> > I think the actual limit to single (not continuted) header line length is
> > to be below 10000 characters. I guess with continued headers you can grow
> > longer. Hmmm I am just guessing here, but I do not think that with
> > continued header lines shall choke  clients. In addition we are aiming
> > for interoperability to new clients like Kmail and we can fix Kmail.
>
> We've recently fixed KMail to deal better with extreme numbers of headers,
> so that is ok, not sure about extremely long headers. 

But then you could fix it. :)

>Can't we do both,
> though? Assuming that the large properties are not usually present (just a
> guess), and since Joon says that most properties are small, I would tend to
> put those in headers and add the large ones as attachments, if and when
> they are needed. 

This does not sound good to me as it introduces even more complexity
in the implementation to split this up and add conditions.

> Since I assume those properties will have a type, be it
> text or image, or pgp signature, or whatever, they could be added as
> regular mime parts with that type, thereby making the information at least
> transparent to other clients.

I assume those data will be binary it might come from plugins that
we do not know that just set their own flags, so there is no chance
to fully understand them. If Joon would understand them I am quite sure
that he would have suggested building a nice mime type for it already.  ;-)

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20050114/9ac30300/attachment.p7s>


More information about the format mailing list