RFC2822 windows attachment

[Bernhard Reiter]

Hi Joon,

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. 

> Adding the attachment is much cleaner, but adding headers is an option.
> What do you perceive are the problems of adding an attachment to the mail
> message?

The disadvantage would be that this is not common to use attachements
for data specific to a singe MUA in RFC2822 emails, but in headers it is.
Not being an experts on the standards this is only a guess, but I currently
do not remember an example where shuch data was added as attachement.
To the body and MIME attachments always was data that all MUAs should
be able to read. 

So with the use of attachements I guess that more people
will frown upon it.  What do others think?
Till, David?


Best,
	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/71d7f9b8/attachment.p7s>