Re: HTML document "attachment" icon

[Brian Stafford <brian stafford uklinux net>]

On Thu,  6 September 13:29 hitched97 wrote:

>  I think you missed the point of the patch - I don't do anything with
>  multipart messages - they still use the (gnome) paper clip icon.  The
>  only thing I changed was messages of content-type text/html, which are
>  currently marked with a paper clip, but with the patch are marked with
>  a document icon, which I based on a netsc*pe icon, because there was no
>  suitable gnome icon available.  Unless you want to make each line in
>  the message list large enough to hold the 48x48 gnome-html icon.
>   In any case, it's not the icon I am concerned about, it's *not* having
>  a paper clip on text/html messages.

Whether a MIME part is considered an attachment or not is somewhat arbitrary
in the absence of a Content-Disposition: header.  There is no right or wrong
behaviour.  RFC 2183 defines the Content-Disposition: header in order to allow
the message sender to specify this information.  In short, if
Content-Disposition: is present on any part and has the value "attachment"
the paperclip should be displayed.  If the value is "inline", the UA should
display the document inline if possible.  If there is no Content-Disposition:
the UA is free to do as it sees fit.

>   These messages do not have an
>  attachement, and it's not appropriate to mark them as such.  I would
>  still like to see them marked in some fashion, to distinguish them from
>  plain text messages.

If a message has a text/html part marked as an attachment, then that's what it
is.  I feel that this status should not be inferred from the MIME type.  OTOH
there is no harm in having an additional icon that indicates the type of the
default MIME part.  determining this could be quite tricky.  E.g. in a
multipart/mixed message with no Content-Disposition headers, the principal part
of the message is anybody's guess.  In multipart/alternative it is the best
rendering of the document supported by the UA (or maybe the highest quality
version of the document?).  Multipart/related explicitly specifies the mime
type of the principal part.  Etc etc...

As it currently stands, balsa's behaviour seems reasonable.

Brian