inline-attachments tag

[Volker Krause]

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 -- volker at kdab.net, vkrause at kde.org
Klarälvdalens Datakonsult AB, Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20070509/203703e9/attachment.sig>