inline-attachments tag
Volker Krause
volker at kdab.net
Wed May 9 16:44:43 CEST 2007
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>
More information about the format
mailing list