From volker at kdab.net  Wed May  9 16:44:43 2007
From: volker at kdab.net (Volker Krause)
Date: Wed, 9 May 2007 16:44:43 +0200
Subject: inline-attachments tag
In-Reply-To: <200610262238.30436.bernhard@intevation.de>
References: <008801c6f35d$ab1cd760$0200a8c0@acerkqjm6rkk68>
	<200610242041.25420.till@kdab.net>
	<200610262238.30436.bernhard@intevation.de>
Message-ID: <200705091644.43679.volker@kdab.net>

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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-format/attachments/20070509/203703e9/attachment.bin

From joon at radleys.co.za  Wed May  9 19:09:22 2007
From: joon at radleys.co.za (Joon Radley)
Date: Wed, 9 May 2007 19:09:22 +0200
Subject: inline-attachments tag
In-Reply-To: <200705091644.43679.volker@kdab.net>
References: <008801c6f35d$ab1cd760$0200a8c0@acerkqjm6rkk68>	<200610242041.25420.till@kdab.net>	<200610262238.30436.bernhard@intevation.de>
	<200705091644.43679.volker@kdab.net>
Message-ID: <001d01c7925c$cdd93840$698ba8c0$@co.za>

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: joon at radleys.co.za
Web: www.toltec.co.za


From bogus@does.not.exist.com  Fri May 18 15:35:00 2007
From: bogus@does.not.exist.com ()
Date: Fri, 18 May 2007 13:35:00 -0000
Subject: No subject
Message-ID: <mailman.8.1190784750.1523.kolab-format@kolab.org>

absolutely certain if this should rather be

 kolab.h-prefs

In any case this folder type will be used to store client preferences,
specifically the Horde preferences. So far Horde used the Kolab LDAP
tree for that but this led to the known problems of including the
Horde LDAP schema in the Kolab server. There were also problems with
the Kolab web admin when using the LDAP based preference system. In
addition it is probably not the most appropriate storage location
since the preferences in Horde are bound to be changed rather often
while a user works in Horde.

As a consequence I would like to store the Horde preferences in a
dedicated "Preferences" folder on the IMAP server.

A draft patch for that would be ready and works fine:

http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE_CVS/file/tip/framework/HK-GW-Prefs-Kolab_IMAP.patch

So my main question is if it okay to declare this new folder type.

This would of course mean that I'd feel tempted to continue declaring
more folders types such as h-links, h-filter, h-bugs, etc. These all
represent existing Horde applications that simply need storage space
(other than the default SQL storage). But I think I remember there was
some opposition concerning the idea of storing additional data types
on the server :)

Waiting for comments!

Cheers,

Gunnar

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                           Bundesstrasse 29
Fax    : +49 40 432 70855                            D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~