[Pan-users] Re: Strange message reading error

[Duncan]

walt <address@hidden> posted
address@hidden, excerpted below, on  Fri, 10 Aug 2007
01:11:22 +0000:

> 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?

There are a couple such flags, yes, but IIRC (and I'm /not/ looking it up 
to write this, so definitely do so or ask for confirmation before using 
this info), both are optional, and may in fact not be part of the 
official MIME spec.

The one flag is that "parts" may have an intended handling flag, 
"inline", "attachment", or "related" (which is like inline, but designed 
to be invoked from another part, think an HTML part referencing an image 
packed as another part).

The other flag is that "attachments" generally include a suggested 
filename, while "inline" and "related" parts likely don't (related parts 
have an ID by which they can be referenced, but not necessarily a 
suggested filename).

Of course, inline parts (text and binary) may also have suggested 
filenames, effectively helping the receiver client to both display inline 
and save, if desired, the affected parts, but that's not necessary.  In 
fact, it's possible that "attachments" wouldn't have a suggested name 
either, simply leaving the name to the client, which could at least guess 
at an extension or handler app to invoke based on mimetype.

If anyone wants something more definitive, like Per's post, ask.  If he 
doesn't expand on this I can.  I just have other things to do ATM if 
nobody has serious use of the info.

>> However the complaint was that the text part was not *displayed* in
>> the message pane, this I too would consider a bug...

> Jim, do you want to file a bug report?  (Otherwise I will file it.)

IMO there's no question, it IS a bug, and should be filed as such.

> And thanks to Per for a great mime lesson.

Indeed.  Even when one has previously studied the info, it's great to 
have a refresher, put in different words too, once in awhile.  That's in 
addition to not needing to do it myself what he already did so well (and 
contrasting with the sloppiness I'm exhibiting above). =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman