Mail structure (Re: Extra Header field)

[David Faure]

I haven't seen this message on the list, so I'll reply to it by quoting it in full.

On Monday 12 July 2004 17:27, Joon Radley wrote:
> > > 2) When there are attachments associated with the object 
> > the message 
> > > is encapsulated in a multipart/mixed content type with the 
> > > multipart/alternative encapsulation described in 1 as the 
> > first body 
> > > part in the multipart.
> > 
> > This needs clarification. There are two ways to read this.
> > Are you thinking of
> > 2a)
> >   multipart/alternative
> >       text/plain
> >       multipart/mixed
> >            application/x-vnd.kolab.note
> >            some_other_attachment
> > 
> > or 2b)
> >   multipart/mixed
> >       multipart/alternative
> >            text/plain
> >            application/x-vnd.kolab.note
> >       some_other_attachment
> > 
> > Karl Heinz mentionned that 2a) might not be legal? (needs to 
> > be checked) But in any case 2b) looks very inconsistent... 
> 
> 2a) is illegal.
> 
> Ok the full mail in case 2
> 
> MIME-Version: 1.0
> Content-type: multipart/mixed; boundary="MIXED-123456"
> Subject: "Kolab Groupware Object"
> 
> --MIXED-123456
> Content-type: multipart/alternative; boundary="STUPID-123456"
> 
> --STUPID-123456
> Content-type: text/plain; charset="us-ascii"
> 
> This is a Kolab Groupware object. To view this object you 
> will need a email client that can understand the Kolab Groupware 
> format. For a list of such email clients please visit 
> http:://www.kolab.org/kolab-clients.html
> 
> --STUPID-123456
> Content-type: application/x-vnd.kolab.note
> Content-Transport-Encoding: base64
>  
> AABBDNNDKIJSGHGSHTUHAK==
>  
> --STUPID-123456--
> 
> --MIXED-123456
> 
> ... a attachment ...
> 
> --MIXED-123456
> 
> ... another attachment ...
> 
> --MIXED-123456--
> 
> > The parsing when looking for the XML would have to really 
> > take both cases into account, and the code for adding an 
> > attachment would have to restructure the whole thing....

This problem remains. The overall structure would change as soon
as one attachment is added, which makes this really not convenient.
How about having the toplevel multipart/mixed in all cases, even
when there's no attachment?

> > It would be much better and cleaner to have a single 
> > structure that works for both cases.
> > In case multipart/alternative (which I don't know much about) 
> > is a problem, why not use multipart/mixed
> >    text/plain
> >    application/x-vnd.kolab.note
> >    some_other_attachment
> > ?   
> > Most mail clients will show the first text/plain attachment, no?
> 
> The mixed/alternate is used for when you want the offer the email client a
> option of what to display. A non-compliant client will see that it only
> understands text/plain and will display this. A compliant client will
> display the application/x-vnd.kolab.note.

Yes. The question was how to also include the attachments in the "for
compliant clients only" part, but apparently that's not possible.

So the next best solution IMHO is to have a *single* mail structure,
which makes it easy to add attachments without reshuffling everything
around.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions