pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] Re: Strange message reading error


From: Per Hedeland
Subject: Re: [Pan-users] Re: Strange message reading error
Date: Fri, 10 Aug 2007 21:40:20 +0200 (CEST)

walt <address@hidden> wrote:
>
>On Thu, 09 Aug 2007 10:20:18 +0200, Per Hedeland wrote:
>
>> walt <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]