Re: inline-attachments tag

On Thursday 26 October 2006 22:38:23 Bernhard Reiter wrote:
> On Tuesday 24 October 2006 20:41, Till Adam wrote:
> > I thought it would serve to distingiush
"real" attachments, things the
> > user has associated explicitely with the object,
from "internal" ones,
>
> I think that Joon proposes another MIME part header
> that indicates, if the attachment should be hidden.
>
> When peeking in RFC 2045 today I saw that there is
already
>
> a designated field for the purpose of mime-parts
refering to each other:
> > 7.  Content-ID Header Field
> >
> >    In constructing a high-level user agent, it may
be desirable to allow
> >    one body to make reference to another. 
Accordingly, bodies may be
> >    labelled using the "Content-ID"
header field, which is syntactically
> >    identical to the "Message-ID" header
field:
> >
> >      id := "Content-ID" ":"
msg-id
> >
> >    Like the Message-ID values, Content-ID values
must be generated to be
> >    world-unique.
>
> One alternative would be to make the Content-ID
mandatory for our Kolab
> format emails and have <attachment> use the
Content-ID for referal.

Was there any decision about this problem?

Kontact recently implemented inline attachments using the
inline-attachments 
tag to distinguish "real" attachments from
internal ones. Since this isn't 
done by toltec, we obviously run into interoperability
problems here, see 
https:/
/intevation.de/roundup/kolab/issue1312 for the details.

So, how should inline attachments be handled correctly?

regards
Volker

-- 
Volker Krause -- volkerkdab.net, vkrausekde.org
Klarälvdalens Datakonsult AB, Platform-independent software
solutions

_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format

Hi Volker,

> So, how should inline attachments be handled
correctly?

The problem with the inline attachment-tag is threefold:
a) The tag was never implemented as we saw during
implementation that it was not a good idea. Why it remained
the documentation is a bit of a mystery.
b) Implementing it now would mean retouching every object on
existing servers.
c) Does not work for normal/RC2822 messages.

What I would suggest that we add a MIME header to the
headers of meta attachments, e.g. X-KOLAB-META: true. We
both currently have code to deal with the Toltec.dat
attachments, so there will be no backwards compatibility
issues. By adding the mime header you can get the same and
even better functionality than the inline-attachment tag.

Best Regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joonradleys.co.za
Web: www.toltec.co.za

_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format