walt <[EMAIL PROTECTED]> wrote: > >On Thu, 09 Aug 2007 10:20:18 +0200, Per Hedeland wrote: > >> walt <[EMAIL PROTECTED]> wrote: >>> ... >>> Appears to me that the "body" of this post is really the first >>> attachment of five, the last four being jpegs. >>> ... >>> What I do think is a bug: the first attachment (which just >>> happens to be text/plain) is not saved along with the jpegs. >> ... >> If I asked pan to "save attachments" for that message, I would *not* >> expect that first text part to be saved. > >Evidently your expectations are in accord with common practice, but >I'm not clear on why this practice is the norm. Is this part of the >mime specs? And what about the case where the 'attachments' just >happen to be text/plain also. Is there something in the mime specs >which requires the 'attached' text/plain to be flagged in some way >as different from the 'body' text/plain?
I think it's essentially a convention (for multipart/mixed) that an initial text part (or text/plain + text/html as I described earlier) is the text that the user composed, and the remaining parts are "attachments" - as MIME formally doesn't have "attachments", the spec can't prescribe what "save attachments" in a user agent should mean - nor do the RFCs prescribe such things in general, they define the on-the-wire "protocol", what user agents do is a "local issue". However as Duncan points out, there is "sort-of" within MIME the possibility to indicate the nature of the different parts. This is done with the Content-Disposition header, which is an optional extension to MIME (see RFC 2183) - it can say among other things "inline" or "attachment" plus a parameter giving a file name, as hints to the receiving UA on how to process that part. I don't think this has much bearing on what a UA will do with "save attachments" though - e.g. in Thunderbird, if I attach a gif and a text file, they will both have "inline", and be *displayed* along with the composed text - but they are still considered as "attachments" for the purposes of saving to file. And getting back to the actual topic, pan's behaviour, it's worth noting that MIME is still relatively unusual in news, at least for the purpose of "binary attachments" - most of them are "non-standard" yenc or uuencode, and the definition of "attachment" may be "whatever comes after a uuencode 'begin' line". --Per _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
