inline-attachments tag

[Joon Radley]

Hi Bernhard,

> Does somebody remember some followup discussion?
> Joon: Are there technical reasons to not just give each 
> attachment a name when you transform the Outlook object into 
> a Kolab-XML format?

What possible benefit can be added to the format by assigning file names to
each attachment? Some attachments are not even files for example RFC2822
attachments.

Secondly you still need to parse the mail structure to find the MIME type of
the attachment. So the information provided by this tag does not offer much.

Thirdly, introducing this field now would require that each object on the
server be re-uploaded.

The only use case we can see for this is where you want to identify the
"hidden" meta data attachments like the Toltec blob that gets added. I think
adding a field to the MIME part header might be a better solution in this
case.

Is there any other use cases that shows the benefit of this 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
 

> -----Original Message-----
> From: kolab-format-bounces at kolab.org 
> [mailto:kolab-format-bounces at kolab.org] On Behalf Of Bernhard Reiter
> Sent: 17 October 2006 12:40 PM
> To: kolab-format at kolab.org
> Subject: inline-attachments tag
> 
> Hi Everybody,
> 
> during the Proko2 contract (=project) we did not complete and 
> test the envisioned attachment functionality for groupware 
> objects, like tasks, contacts, appointments between clients.
> 
> Now that we are correcting the Kontact implementation [2], we 
> found an inconsistency in our understanding of the spec.
> This is about (see spec [1])
> 	inline-attachment (string, no default)
> 	link-attachment (string, no default)
> 
> Joon wrote [3]:
> >     The inline-attachment tag was supposed to be removed from the 
> > specifications. When everybody was working on it we found that some 
> > attachements did not have names, so what is the purpose of 
> the field 
> > if it only listed part of the attachemens.
> 
> I only found a post on kolab-format from September 2004 [4].
> Joon, you did agree with the proposal way back:
> 
> > > I propose we do these two:
> > > 
> > > <inline-attachment>filename</inline-attachment>
> > > <link-attachment>URL</link-attachment>
> > > 
> > > Where the first is the current behaviour and the second 
> contains a 
> > > valid URL.
> > 
> > This sound fine. AFAIK Outlook does support referenced attachments, 
> > but I will need to spend some time on this to make sure. If 
> not or I 
> > cannot make it fit, I will just preserve the tag.
> 
> Does somebody remember some followup discussion?
> Joon: Are there technical reasons to not just give each 
> attachment a name when you transform the Outlook object into 
> a Kolab-XML format?
> 
> Best,
> Bernhard
> 
> [1] http://www.kolab.org/doc/kolabformat-2.0rc3-html/c132.html
> 
> [2] https://intevation.de/roundup/kolab/issue1312 
> (Attachements in Tasks and
>  	Events (Outlook vs. Kontact))
> [3] https://intevation.de/roundup/kolab/issue1439
> [4] 
> http://www.kolab.org/pipermail/kolab-format/2004-September/000370.html
>