RFC2822 windows attachment

[Till Adam]

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. 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. 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. Hiding those parts could maybe be achieved via 
content-disposition attributes of the mime parts, if desired, not sure off 
the top of my head whether that would work, though. Joon, does such a scheme 
make sense to you? I'm not sure I completely understand what the problem is 
that this is attempting to solve, in other words what kind of information you 
are meaning to store in the mails.

Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20050114/3f73739f/attachment.sig>